What about the “workspace” feature? For example, you would have many projects grouped into 2 ones.

/home/foo/group_A/project_01
/home/foo/group_A/project_02
/home/foo/group_A/project_03
/home/foo/group_B/project_11
/home/foo/group_B/project_12
/home/foo/group_B/project_13

And you should have settings below.

require("telescope").setup {
  extensions = {
    frecency = {
      workspaces = {
        group_A = "/home/foo/group_A",
        group_B = "/home/foo/group_B",
      }
    },
  },
}

1. First, you open some files in group_A.
   • /home/foo/group_A/project_01/README.md
   • /home/foo/group_A/project_02/package.json
   • …… etc.
2. You do :Telescope frecency and you see candidates in group_B at the top. Yes, this is annoying.
   • /home/foo/group_B/project_11/README.md
   • /home/foo/group_B/project_12/index.html
   • /home/foo/group_B/project_11/lib/foobar.c
   • /home/foo/group_A/project_01/.eslintrc.yaml
   • /home/foo/group_A/project_01/lib/main.js
   • /home/foo/group_A/project_01/README.md
   • /home/foo/group_A/project_02/package.json
3. If you want to limit candidates into projects inside group_A, you can do :Telescope frecency workspace=group_A and see ones below.
   • /home/foo/group_A/project_01/.eslintrc.yaml
   • /home/foo/group_A/project_01/lib/main.js
   • /home/foo/group_A/project_01/README.md
   • /home/foo/group_A/project_02/package.json

Can this solve your issue?

@delphinus many thanks for taking a look at my request and even coming up with the suggestion, yes, I think, definitely makes sense! That's actually quite close to what I mean, but obviously needs some part of pre-configuration of the workspaces to be used. This is also a way to go, given the projects are usually long-term and it's not a big deal to print a line in the config.

What I'd ultimately love to see is actually the same workspace which is collected on the go, some kind of "live workspace" in these terms. I think, it's handy to have not only because less configuration, but also following the essence of the programming process, which is quite creative and changing and at times you even don't know what project or what workspace you're in at the moment — you just seem to remember you've seen that nice piece of code a couple of files ago :)

I see. Yes, my plan needs pre-configured structure of repositories. It is ideal that telescope-frecency can attach importance to candidates that are in the same projects as already opened ones.

I'm thinking two plans to implement. As precondition, you have these candidates as below.

Plan 1: Only opened files precedes against others.

When you have opened (B2) and (A2), :Telescope frecency shows this:

 60  ~/project_B/index.html   -- opened
 20  ~/project_A/LICENSE      -- opened
100  ~/project_A/lib/foo.js   -- not opened
 80  ~/project_B/README.md    -- not opened
 60  ~/project_B/index.html   -- not opened
 40  ~/project_C/package.json -- not opened
 10  ~/project_B/image.jpg    -- not opened

Plan 2: All candidates in the same projects precedes.

In the same situation: you opened (B2) and (A2), then see this.

100  ~/project_A/lib/foo.js   -- not opened
 80  ~/project_B/README.md    -- not opened
 60  ~/project_B/index.html   -- opened
 20  ~/project_A/LICENSE      -- opened
 10  ~/project_B/image.jpg    -- not opened
 40  ~/project_C/package.json -- not opened

Probably your plan is Plan 1. But I think Plan 2 is effective for some situations. Which one do you like or both plans?

Thank you for such a detailed illustration to both of the directions! It really helps to clarify the ideas.

Yes, indeed, I like Plan 1 a little more and that's exactly what I initially meant. Basically, I see a couple of pros in favour of it:

• (biased) I usually work with C++ projects which tend to contain quite a big number of files, so they would easily fill the screen with Plan 2
• I'm not sure, but detecting that certain files are belong to some same project sounds to me as a separate complex task, though there seem to be plugins for that, maybe it's possible to use some of them

Still, your Plan 2 looks quite interesting to me, too. I haven't thought of something like that, but with your illustration it looks nice and natural to use and also looks like a step forward in the way of the workspace concept (something like "auto-detect projects as workspaces"). So now in my ideal world I see both of these, but yes, I think, any of them which is easier to implement would be great to have.

@aclex

I've Implemented both Plan 1 and Plan 2 in #274 (still draft). Can you test this? You can achieve your plan with preceding = "opened" option.

I am also thinking names for the option and its values: preceding, opened, same_repo. I'm happy if you can propose easier and clearer words for them.

@delphinus thank you very much for the implementation of both scenarios! Such a quick one!

Sure, I've just switched to the feature branch in my configuration to try it in the real work. I've only just added a couple of little fixes to make it work as I would expect, at least for the Plan 1 scenario, I'll publish a pull request for it right away. Sorry, I'm not the best Lua programmer, so that's pretty much only a proof of concept) It also tends to make Plan 2 work following your previous illustration.

As for naming, maybe I'm a little subjective being deep in the context after our discussion here, but all the terms look very clear to me. So, in my opinion, they are just fine.

Many thanks again for implementing it! Oh, I'm just happy, it looks like what I really wanted to make my every day work in neovim much more pleasant! :) Well done!

@aclex Thank you waiting for merging #274. You can now use this feature.

@delphinus oh, brilliant! Thank you very much for making it possible, for your great help with this feature and for your kind and constructive approach! It was a pleasure to discuss all the details here and finally come to so nice implementation.

I wish all the best to your project! Will be use it with even more comfort now and yes, would be happy to return with another idea sometime :)

Thank you very much!