Allow selection of files

[pothos]

I think it would be useful to allow file selection, too. E.g., with less $(env tere) one could read a selected file. I guess it makes sense to define a special shortcut for file selection, like Alt-w instead of Alt-q. Using Enter would also work, though if the caller passes a special argument when invoking tere, like --allow-files.

[mgunyho]

I'm a bit undecided on what tere should do with files. Here's some brainstorming.

What you suggest would be pretty useful, but the UI needs to be thought through carefully. One option that I have considered is to call xdg-open on files, which would conflict with this use case.

Maybe tere could ask what you want to do with the file (print or xdg or nothing), with some CLI args for setting the default option which would be invoked by just pressing enter) and maybe another for disabling the confirmation. And maybe it needs to be configurable if you want to return to tere after the ppager or whatever command finishes, not sure.

What do you think? Can you come up with some other use case?

(Note that I will be offline for the next couple of weeks so I might not be able to respond for a while)

[pothos]

I would stick to the current working principle of printing the selection to stdout. Having a menu inside tere is an interesting idea but since it is not really required and is a larger problem to solve, I would not care about it in the beginning but maybe later (I also think that xdg-open does not work well for file actions in general).

[chapmanjacobd]

printing the selection to stdout

I also agree with this. It's easy for someone to create an alias for tere | xargs xdg-open

Can you come up with some other use case?

right now tere overlaps with $fish_complete_path so I don't really have a use for tere.

Fish shell provides $fish_complete_path as a built-in feature where you can just start typing and it will help you complete the path that you want. You can press tab multiple times to see multiple results even if you haven't typed anything initially--in other words it is deeply integrated into the shell.

But $fish_complete_path has two limitations:

1. For folders with many files or directories it can be quite slow. (maybe 14 seconds on a folder with 2 million files)
2. Selection of multiple files/folders is kind of possible but limited to items which have the same prefix

For context, when searching for a specific file type in a large folder I would just do this:

fd -tf -eWEBM --max-results=1

I can think of two use cases where tere could shine:

1. exploring a large folder without loading all the folders or files from filesystem metadata. If tere is optimized to only scan to show the initial display (~number of items equal to terminal view/rows) and then continue scanning in the background then it could feel very fast even for large folders
2. selecting multiple disparate folders or files (maybe alt+f could be used to toggle between showing file and folder)

[orhun]

I also agree with this. Adding this feature would be great. Enter key press simply can print the selected file to stdout instead of "Not a directory" error. I can work on a PR if it is applicable.

[mgunyho]

This could be implemented, but what should the shell wrappers be then? Consider this:

tere() {
    local result=$(command tere "$@")
    if [[ -d "$result" ]]; then # check if directory
       cd "$result"
    elif [[ -f "$result" ]]; then
       # what goes here?
    end
}

Or, do we completely get rid of shell wrappers and instead recommend the usage to be cd $(tere) or my_program $(tere) depending on the use case? That's a lot of annoying typing.

Or if we broaden the scope of tere to be a general file selection program (so that basically it becomes just a different flavor of fzf), we need to rewrite the whole shell wrappers/aliases part to include multiple different examples for each shell.

If the user has to decide at the time of launching tere whether they want to print a folder or file, there's a risk of bad UX: if I'm expecting to cd, but then accidentally select a file while browsing (happens to me every now and then), I get an annoying cd: my_file is not a folder error and get thrown back where I started. To not have this happen to all existing shell configurations, this should definitely be behind a flag like --allow-files.

Maybe this is an argument in favor of #46, but that has it's own list of papercuts as discussed there.