Should have file indexing and jumping

[euank]

No description provided.

[euank]

To add a bit more information here:

fasd has this feature where it adds files to its frecency database and lets you do things like vim $(f foo) or v foo, which can be quite nice.

It's implemented in a few different ways:

1. Any command you type has all arguments realpath'd + -e'd
2. (off by default) It uses "backends" like viminfo and ls $PWD to discover files (see here)

To expand further on 1, the relevant code is here.

Effectively what it does is process each command you type for possible paths.

For example, if you type sudo cargo build --release && ./target/release/pazi, the following happens:

1. sudo is recognized as special and ignored.
2. cargo is recognized as a command, and ignored
3. All of build, --release, and ./target/release/pazi would be realpath'd and added if they exist, probably just the 'pazi' binary in this example. Note, the && is sanitized out
4. These would now be available for use in f and v and so on, woo!

I'll also quickly note that things like echo have special handling as well to avoid adding said files.

Now, frankly, I find the above to be quite hacky.

However, the feature is of such great use, I'm willing to accept some level of hackery to get it, though I will insist such hackery should happen in rust, not sed/shell/whatever.

That being said, I would much rather instead find a less hacky solution. If anyone has an idea, I'd be happy to hear it.

My current less-hacky ideas are:

1. Implement a smaller subset of what fasd does (e.g. only viminfo, or pulling from only a subset of commands which we can fully parse, which seems marginally better)
2. Use mlocate.db or such and rely on an alternative tool to scan for files and directories, lean on that tool for files entirely (downside: no frecency)
3. Use perf instrumentation to find files accessed by the user, add those to the database (downsides: perf, might need a daemon running, might be too much data, requires recent kernel, hacky).

I think there may be value in looking into the possible other sources for 2, and also into examining how bad of an idea 3 really is.

[benmccann]

As a user, the backends (such as viminfo) are the least useful portion of this to me, so I wouldn't be bothered by not having that.

[euank]

Capturing another requirement from another issue:

It should be easy to make aliases that allow doing things like opening a file in an editor or cd-ing to a directory.

I think all pazi needs for that is to have something like z --type=file|directory, and that makes the aliases possible.
I think it would default to z --type=directory if nothing was set, and I don't know if there's any usecase for --type=both.

I was assuming, though didn't state it explicitly, that files and directories would be stored in separate frecency databases (meaning limits on total counts and filtering would be separate between em).