Feature Requst: File picker based on current buffer's directory

[paholg]

I will often "go to definition" for library code and then want to explore that library, but have no good way of doing that.

Being able to open a picker based on the current buffer's file location, and having a way to "go up a level" in the picker (like emacs' helm-mode's ctrl-l) would solve this.

I am also interested in if anyone has a workaround for exploring library code without re-opening helix in the library directory.

[sudormrfbin]

Related: #2481.

I am also interested in if anyone has a workaround for exploring library code without re-opening helix in the library directory.

You could :cd into the library directory, but there's no way currently to quickly enter the path of the current file into the command line (#2985).

[QiBaobin]

I am adding a register % to match current file name, but I don't know how to use it in the config.toml.

If it's a OK, I would like to make a PR to let 2 + space + F open the file picker on current buffer's directory.

[the-mikedavis]

I don't think we should use counts to modify behavior unless the behavior depends on the number (like repetitions). With this there would be quite a few file opening commands - maybe we should have a sub-map in space for file pickers? Or we could have a sub-map just for the specialized ones: leave <space>f and use <space>F as the leader for picking from the current directory, the current buffer's directory, etc.

[the-mikedavis]

This picker would also be useful in languages with lots of directories in their namespaces like Ruby or Elixir: you tend to have a collection of somewhat short modules in a directory instead of larger more monolithic modules all combined into one directory (like with Erlang for example). Being able to jump to other modules in the namespace could be useful.

[QiBaobin]

This

I don't think we should use counts to modify behavior unless the behavior depends on the number (like repetitions). With this there would be quite a few file opening commands - maybe we should have a sub-map in space for file pickers? Or we could have a sub-map just for the specialized ones: leave <space>f and use <space>F as the leader for picking from the current directory, the current buffer's directory, etc.

This does make a lot sense, would open a PR for it.

Added below mapping:

#### File mode

This layer is a kludge of mappings, mostly pickers.


| Key     | Description                                                             | Command                             |
| -----   | -----------                                                             | -------                             |
| `f`     | Open file picker                                                        | `file_picker`                       |
| `F`     | Open file picker at current working directory                           | `file_picker_in_current_directory`  |
| `d`     | Open file picker at current buffer's directory                          | `file_picker_in_buffer_directory`   |
| `c`     | Open the helix config.toml file                                         | `config_open`                       |
| `l`     | Open the helix log file                                                 | `log_open`                          |

[kee-oth]

I just want to ping this thread as this functionality is something I'd really enjoy in my workflow. I do most of my work in projects where sibling files are highly relevant (frontend JS/TS work).

Is this something Helix is still interested in pursuing? Thanks!

[Elias-Graf]

I find myself wanting this quite a lot when working with angular, or any other framework / language that has multiple strongly correlated files in the same folder.

My first thought was "a file picker in the current directory", but thinking about it, a file picker that just shows me the sibling files at the top of the list would do the trick. Not sure if you guys want to modify the sorting behaviour, but given the filtering still applies, it shouldn't be that big of an issue.

The file picker could also prioritise recently opened files, but I guess that's a different matter.

[cbclemmer]

I was looking at this issue and had to click through a few different links but there is a PR open for this for future reference #2707

[the-mikedavis]

#2707 is for #2558. This is covered by #4666

[tennix]

This

I don't think we should use counts to modify behavior unless the behavior depends on the number (like repetitions). With this there would be quite a few file opening commands - maybe we should have a sub-map in space for file pickers? Or we could have a sub-map just for the specialized ones: leave <space>f and use <space>F as the leader for picking from the current directory, the current buffer's directory, etc.

This does make a lot sense, would open a PR for it.

Added below mapping:

#### File mode

This layer is a kludge of mappings, mostly pickers.


| Key     | Description                                                             | Command                             |
| -----   | -----------                                                             | -------                             |
| `f`     | Open file picker                                                        | `file_picker`                       |
| `F`     | Open file picker at current working directory                           | `file_picker_in_current_directory`  |
| `d`     | Open file picker at current buffer's directory                          | `file_picker_in_buffer_directory`   |
| `c`     | Open the helix config.toml file                                         | `config_open`                       |
| `l`     | Open the helix log file                                                 | `log_open`                          |

#4666 adds a command for file picker, but does not have a keybinding for it. And the <space>d keybinding is already taken by diagnostic picker.

By reading helix-term/src/commands.rs, the file picker uses git root directory or fallback to current working directory, while the file picker at current working directory is the fallback mode for file picker. I think most people would just cd into the project root directory and run hx there. This makes the two keybindings have the same effects. So I would suggest making <space>f for open file picker at current buffer's directory and <space>F for open file picker. And just remove the open file picker at current working directory.

@the-mikedavis What do you think about this suggestion? Also a kind reminder, PR #4666 has changed a bit after your approval, so need an approval again :-)

[the-mikedavis]

the file picker uses git root directory or fallback to current working directory

It's a bit different: it's the LSP workspace directory. So the file picker matches what the language server sees as the root directory for the project.

See the discussion in #3063. We don't want to remap the current <space>f.

[tennix]

The command file_picker_in_current_buffer_directory is used to open file picker in current buffer directory, however it's not bind to any key yet. For those who want to use this, it's easy to bind it space mode by adding following to your config file

[keys.normal."space"]
o = "file_picker_in_current_buffer_directory"

<space>o would open this file picker

[dbarnett]

I am adding a register % to match current file name, but I don't know how to use it in the config.toml.

Was there any further discussion on adding a placeholder like % for current file name? In vim I'll often do stuff like :vsplit %:h<TAB>/otherfile, but for helix it looks like out of the box there's still nothing more ergonomic than typing out the whole CWD-relative filepath?

[dbarnett]

With this there would be quite a few file opening commands - maybe we should have a sub-map in space for file pickers? Or we could have a sub-map just for the specialized ones: leave <space>f and use <space>F as the leader for picking from the current directory, the current buffer's directory, etc.

Would you ever consider, from the file picker itself, some shortcut to change the base directory? That way instead of relying on a profusion of separate "file_picker_in_X_directory" commands, I could just open the file picker and then have options from there to pivot the base directory I'm picking from.

[paholg]

With this there would be quite a few file opening commands - maybe we should have a sub-map in space for file pickers? Or we could have a sub-map just for the specialized ones: leave <space>f and use <space>F as the leader for picking from the current directory, the current buffer's directory, etc.

Would you ever consider, from the file picker itself, some shortcut to change the base directory? That way instead of relying on a profusion of separate "file_picker_in_X_directory" commands, I could just open the file picker and then have options from there to pivot the base directory I'm picking from.

I have a branch to add keybinds to navigate the picker to child or parent directories. It was not approved for merging, but I am using it and periodically rebase off master of you want to try it. I still find opening the picker in the current buffer's directory quite useful though. I often use them in conjunction -- I'll go-to definition, then open picker in buffer directory, then move the picker to parent directories to browse library code.

https://github.com/paholg/helix/tree/file-picker-navigation

[dbarnett]

That's great! They were resistant to merging when you sent a PR for some reason?

I'd imagined some way to jump to buffer parent too… maybe just typing % into the picker and hitting ctrl-e from your mechanism, if they'd be willing to support that path placeholder?