Getting projections out of pre-release

[GnikDroy]

How to suppress the notification?

Switch to the pre_release branch. A new notification will arrive when the major version is released.

Development is over at dev

1.0 is planning to include:

• A telescope previewer to preview project directory. Any suggestions regarding the contents of the "preview" pane are welcome.
  

• A way to minimize setup boilerplate.
  The minimal config is currently

  { 'gnikdroy/projections.nvim', opts = {} }

  Projections will by default take care of autocmds/loading extension/setting up keybindings/user commands etc. This will not give up too much control if you want to do things manually.
  You can take a peek at the default options over at the dev branch. Any suggestions for the default values are welcome.

• Remove the dependence on vim.loop. vim.loop will be renamed to vim.uv in Neovim 0.10

• Updated emmylua annotations

• :checkhealth impl for projections

• Improve load time by lazyloading telescope

• Project selector falls back to vim.ui.select if telescope was not found

• Solutions for Keep track of current project #30 and [feat] tab scoped sessions #40. Projections will keep a stack of projects and expose :ProjectionsNextProject and :ProjectionsPreviousProject as well as a Lua variable containing the list of projects.

If you want any other features. Please mention them here. Mentioned features can be voted for with thumbs up/down.

My time is limited. Any contribution regarding the above will be appreciated. Just make sure to create an issue first.

[GnikDroy]

FEAT: Manually adding projects / Searching for projects

This as been mentioned before by multiple people now. I personally dislike having to manage the list of projects manually. Or having neovim needlessly search for projects. But we can make things more flexible.

So instead of, workspaces = { },
We can have projects = { } which take in generators.

Things like projects_from_workspace() and projects_from_list(), projects_from_search(), projects_from_history(), projects_from_lsp() etc. which are all generators for projects. Projections already has the mechanism for projects_from_workspace(). It is possible to implement all the other "common" scenarios as well.

Personally, I think this is unnecessary. I would like to keep the plugin simple, since it is easy to maintain. But if this is something that users want, then this will be seriously considered.

[sandersantema]

Fyi: both packer and lazy.nvim report breaking changes. Afaik packer does so by looking for the string "breaking change" case insensitively and lazy.nvim does so by looking for the lua pattern ^%S+!:. So a commit message containing breaking change!: or similar should warn users of both plugin managers about important changes without forcing users to switch to a different branch or having to manually dismiss a message on each startup.

[GnikDroy]

@sandersantema I am aware. But not everyone uses lazy.nvim or packer. Additionally, there is currently no breaking change. Everything works, apart from the annoying message at the start.

Hopefully this is not too bothersome. I can just revert the commit and add a breaking_change in the commit message. But that is probably worse, because people will expect projections to stop working and expect it to need immediate attention.

[rwaltr]

Howdy, reporting in after seeing the notification in Nvim and wanted to add my 2 cents to the conversation,

I am one of the users that would want more control over the projects that projections sees. As for me, not every object I want to interact with is a workspace

For example, The following is an example of projects I would like projections to know about.

~/src/[github_usernames]/[repo]
~/src/[employeer]/[repo/subproject]
~/.local/share/chezmoi

For the first line, The way projections would digest this is that every GitHub username is a workspace. This is an easy workaround

    --- exports table of dirs in "~/src/"
    ---@return table workspaces
    local function yankworkspaces()
      local workspaces = {}
      for name, type in vim.fs.dir("~/src/") do
        if type == "directory" then
          table.insert(workspaces, '~/src/' .. name)
        end
      end
      return workspaces
    end

The second line I believe works as you intended, and as a bonus, gets included with my workaround above.

The 3rd line is an oddball. This is part of a toolset I use for dotfiles, this repo exists here by default, I would prefer not to move this to another location.

In actuality, this is helped by the patterns detection, and nothing else in that pattern matches for my version of the directory, but I originally would have preferred to just add this one project to the list.

    local workspaces = yankworkspaces()
    table.insert(workspaces, "~/.local/share")

    require("projections").setup({
      workspaces = workspaces,

      patterns = { ".git", ".svn", ".hg", },
    })

In the end, I would have preferred to add projects independently as an option. But was able to work around it without too much effort.

[GnikDroy]

@rwaltr
Please note that you can symlink odd ball projects like this to a common directory and then include that as a workspace.

So, symlink ~/.local/share/chemzoi to ~/src/orphan_projects/chemzoi and then include ~/src/orphan_projects as a workspace. This means the bookkeeping is done by the filesystem instead of projections. Programs outside neovim will also be able to take advantage of this organization.

1. Is the symlink method good enough for you?
2. If you do not like the symlink approach, what do you think about the project generators support I mentioned earlier?

[GnikDroy]

Let me expand further on how the generator support would look like:

projects = {
    -- from_workspace and from_search will be combined through the depth parameter
    -- depth == 1 is default
    from_workspace = {
        { path = "~/source", patterns = { ".git" } }
        { path = "~/projec", patterns = { ".git", ".nvim.lua" }, depth = 3 }
    },
    -- Some attached lsp clients have `root_dir` set-up.
    -- if projections detects any lsp client which contains this,
    -- it will automatically remember the root_dir and consider it a project
    -- this means, editing a single file from a project (with lsp) would give you
    -- automatic detection of that project
    from_lsp = true,
    -- Now that nvim supports .editorconfig files
    -- we can use the `root` key from there to detect projects.
    -- if projections finds any such editorconfig files up the dir tree,
    -- it will remember it as a project
    from_editorconfig = true,
    -- Everytime a named buffer with a filepath is opened
    -- we will navigate up the directory tree.
    -- if we find any files/folders in `default_patterns`,
    -- projections will automatically remember it as a project
    from_smart_detect = true,
    -- manually specifiy projects here.
    -- you can also use any custom method of project specification.
    -- for example, from_list = your_logic_that_generates_project_list()
    from_list = {
        "~/dev/project_a",
        "~/dev/project_b",
    },
}

As you can see, there are a lot of ways project detection can be done.
But with added flexibility comes added complexity and bugs.

Personally, I am more interested in from_lsp, from_smart_detect and from_editorconfig
than from_list. But it is a ton of work either way.

[rwaltr]

Symlink would work for most situations, except for 1, My Neorg notebook. I would need to find an imaginary root patterns for it to work, and moving that to src does not make sense as it's not source code. I'll give that a shot on my system and see what that experience feels like.

Furthermore, I do find interest in the generator way as well. But instead of trying to define multiple generators at the start, which would force the generators to be maintained within projections very closely, I think a public function that would allow you to append projects or tables to the list would be more sustainable.

Some pseudocode to elaborate my concept.

projects = {}
projects = projections.util.generators.workspace({
        { path = "~/source", patterns = { ".git" } }
        { path = "~/projec", patterns = { ".git", ".nvim.lua" }, depth = 3 }
})
projections.add_projects(projects)

Elsewhere, maybe in an Autocmd

-- Logic for LSP detection
projects = {}
projects = LSP_detected_projects(lsp_client)
projections.add_projects(projects)

-- Psudocode
function add_projects(projects)
for i in projects
 if projects exists
return 0
else
-- insert project into storage
return 0
end

I think this would cover the best of both worlds, it allows for internal and external generators, single static projects, and enough flexibility for anything else we have not thought of. While hopefully keeping the core logic of projection's project storage down.

---

Looking deeper into the dev branch, I see what you are talking about in terms of the work it would take to store things at a project level vs workspace level.

[GnikDroy]

@rwaltr
Can you explain what you mean by imaginary root patterns? If patterns is set to an empty list, projections will consider all subdirectories inside to be projects (patterns is ignored)

projections.util.generators.workspace This is fine. Although we still need to keep the code for this inside projections. So, it would also force the generators to be maintained within projections. I think maintaining it within projections is fine for the common generators. For, allowing external generators, I was thinking from_list could be used. from_list = user_generator()

projections.util.generators.* approach is perfectly fine though. I did think of this in my initial draft. If I implement this, I will have to take a look at which method is easy for users to configure/reason with.

[rwaltr]

Can you explain what you mean by imaginary root patterns?

My notebook is in ~/Documents/personal/notebook, this is not a git repo.

Currently, I would either...

• need to import ~/Documents/personal as a workspace with no patterns, meaning my document's folder becomes a large list of false projects.

• Symlink notebook to src, It would not autodetect because it does not have .git, .svn, .hg. So I either import SRC with no pattern or create a new pattern .neoconf, .neovimroot,.neorgroot to add to my source.

• Import ~/Documents/personal/ as a workspace with a pattern like the above

For, allowing external generators, I was thinking from_list could be used. from_list = user_generator()

While this is fine, I was mainly thinking of this as something I would be able to call after projections.setup() multiple times.

projections.util.generators.workspace This is fine. Although we still need to keep the code for this inside projections.

Indeed, I was thinking these would be the generators that you would want to create/maintain, and that these would be public for anyone who would want to have more direct control on how the generators are used, then feed the results of their generations into projections.add_project or from_list.

---

In my head, the list of projects that projections would have would be a large singular list, As a user, I would want to append anything to that list, and Projections would ignore any duplicate additions based on the path.

[GnikDroy]

Sure, I can implement workspace with depth and ability to add projects from a list for the 1.0 release. I will try to squeeze in one of lsp/smart if I get the time. Any further generators will be slowly added over time.