nvim-telescope / telescope-project.nvim

MIT License
607 stars 54 forks source link

Feature/Workspaces #43

Closed claidler closed 3 years ago

claidler commented 3 years ago

Workspaces

Let's get workspaces done.

It's been on the roadmap for a while now. I would like to put some thoughts out there and get some ideas flowing.

What is a workspace?

A workspace is a place that contains a number of a users chosen projects.

What is the purpose of a workspace?

Sometimes a user will work on a project that contains lots of different projects. For instance, a server, a website and a cms. It would be nice for the user to press ctrl+p to bring up telescope-project and only see the projects that they are currently working on, and to switch between groups of projects at any given moment. Another example would be for a user wanting to see all of their work projects and then switch to all of their personal projects seamlessly. The purpose is to reduce noise.

How do we implement it?

The user's guide

I'm not sure about the key commands yet - I just plucked them out of thin air.

The dev's guide

claidler commented 3 years ago

I would really appreciate any thoughts/ideas/suggestions - related or unrelated, ordinary or insane

kkharji commented 3 years ago

😍 Great idea @claidler . Yes, workspaces would be a powerful addition. I agree, Real-world Projects tends to grow to be made of multiple codebase. It would be nice to have them all shown with a signal hotkey, and navigated between them intuitively.

Feedback

The user's guide

Is these mappings only active in the telescope picker (normal/insert?) or globally

A workspace is a place that contains a number of a users chosen projects.

Do you mean each workspace contains a related set of gitrepos? defined or added somehow by the user?

e.g. Github Org (Workspace): Github UI Library, Github Backend Library, Github Backend Z, Github Backend Y, Main Github Frontend, ... etc

ctrl+1 ... ctrl+9 will open workspaces 1-9 (it's capped at 9, would people want more than 9?)

No, if they have the ability to archive workspace? For example, I no longer work at Github, or taking a vacation, I'd like to archive it, and be able to restore it. Another example, maybe I'm learning a new language and building demo projects and then archive the workspace for later, when I want to search the workspace or quickly open the workspace without activating it and see what projects it holds.

This way, users wouldn't need more then 3 active workspace, and thus maybe we should default the number of workspace to 5.

ctrl+0 is the default, which shows all projects across all workspaces.

Can please you elaborate more here

The default workspace (on telescope project open) will be specified in the telescope-project setup config, in the users nvim config.

Hmmmm 🤔 , I'm not sure about this one. Maybe no default workspace, and instead have a workspace picker and the user would open it and choice a workspace on a new nvim instance.

ctrl+w, m, 1 move project to workspace 1 (read as ctrl+workspace, move, 1)

Some users would like to rather have a command that prompts them to choose a workspace, maybe ctrl-w, m, m.

currently all projects are saved in the telescope-project text file with a number of properties, separated by '='. We just add another property for workspaces - w1...w9. we update and delete as you'd expect, by removing or updating the w1...w9 for the specified project.

Oh that would be a simple and straightforward manipulation. We need wrappers to add, remove, move projects, as well as workspace archive and shift position (1->2).

Suggestion and consideration:

claidler commented 3 years ago

Hi @tami5. Thanks for this.

Are these mappings only active in the telescope picker (normal/insert?) or globally

Good question, I think globally (insert and normal mode), as you may want to switch between workspaces at any moment.

Do you mean each workspace contains a related set of gitrepos? defined or added somehow by the user?

Yes. Git repos or just standard directories, that have already been defined by the user as 'projects' within the telescope-project plugin.

Have the ability to archive workspaces

This is a nice idea, and a good example of what I hoped for by opening this as a discussion. It's seems more like a phase 2 thing, but something we should consider for sure.

This way, users wouldn't need more then 3 active workspace, and thus maybe we should default the number of workspace to 5.

I see your point, but I think if we have 9 number keys on the keyboard and the implementation isn't changing, why limit the user to less than 9?

ctrl+0 is the default, which shows all projects across all workspaces

I created an image for this, as I thought it would be easier to visualise it:

IMG_20210623_075944

Excuse my handwriting! Here you can see W1 (workspace 1, activated by ctrl+1), shows projects in workspace 1, and ctrl+2 shows projects for workspace 2. Ctrl+0 shows projects for all available projects across all workspaces - basically what we have currently (as if workspaces don't exist). The reason for this is that some people might not want to use workspaces, or they might want to work across projects in all workspaces. We can't assume people's use cases.

Maybe no default workspace

I think a default workspace is a good idea for convenience. For instance, if a user know's they need to work in 1 workspace for the next month or so, they won't want to tediously go through the menu of workspaces each time they open the project picker.

Have a workspace picker that the user would open to choose a workspace

Good idea, and something I should have considered. There is a chance that people will forget what is on a given workspace, so we would need a way of naming workspaces. I think ctrl+w, w would be a good mapping for this. In order to name workspaces I suggest we use a new workspaces txt file also as a kind of relational table, to specify a workspaces name and other attributes moving forwards. I did a basic image for this also:

IMG_20210623_080355

Some users would like to rather have a command that prompts them to choose a workspace, maybe ctrl-w, m, m.

I like this idea too. I think we should get all these ideas down and then split them into phases. We can get a basic implementation down, and then add more features.

As a user, when I open a new neovim instance and open a project X, when I click

Sorry, I'm not sure what you're suggesting here.

As a user, it would be nice to restore the workspace tabs, windows, layout and be promoted with (restore session yes/no)

Yeah, I've thought about sessions a few times. It's a big one I'd like to come back to and I think it makes more sense with workspaces than it did with individual projects.

Command palate for all project/workspace functionalities (add/remove current git-repo/project to/from a workspace)

Yeah interesting idea, but I'm not sure on this one. I think vim users tend to be okay with learning key commands, that we hopefully won't need a command palette, maybe we could show the available commands somewhere though or have something like vim fugitive's g? command.

matu3ba commented 3 years ago

Great to hear! Love the plugin so far and use it daily.

Some unclear questions for me of the proposal:

  1. How is the workspace PATH defined that one changes to?
  2. Would workspaces then be defined as text file workspaces.txt inside $HOME/.local/share/nvim with
    workspace1 title
    project1
    project2
    project3
    ...
    workspace3 title
    project4
    project5

    with project names and paths and workspace titles being distinct?

  3. How complex do you want this plugin to become? I would be against sessions to keep stuff simple. So far the telescope-projects.txt is nice and simple.
  4. Do you use harpoon? https://github.com/ThePrimeagen/harpoon It would be nice, if the format of stuff would be specified so other plugins can reuse the project information and to keep it simple. Probably even with the lua snippets how to read that information.

Use case for 4: Often one has shell stuff, which are reoccurring for tasks but not long enough or complex to justify cluttering the repository, ie something like watchexec -e rs 'cargo +nightly test --lib && bash tests/run_examples.sh && cargo +1.53.0 clippy &> clippy.log'. Would be nice to have a treesitter search for that, which can rely on the project information to execute the scripts in the proper project paths.

kkharji commented 3 years ago

Good question, I think globally (insert and normal mode), as you may want to switch between workspaces at any moment.

Normal mode would be okay, insert mode, c-w is used often to deleted the previous word.

why limit the user to less than 9?

Idk 😆, it personally overwhelming. but yes 9 sounds the maximum number of workspaces any develop could possibly have. But again with archive feature this 9 or 20 wouldn't be limiting.

I created an image for this, as I thought it would be easier to visualise it:

Wait so when the user clickc-1 he would launch telescope prompt with the projects in workspace 1? and yes c-0 to show all project make sense.

I think a default workspace is a good idea for convenience. For instance, if a user know's they need to work in 1 workspace for the next month or so, they won't want to tediously go through the menu of workspaces each time they open the project picker.

I see it's usability, it make sense to have a default workspace.

relational table,

well I've create sql.nvim for that purpose 😂, feel free to consider it. as I believe it will make things much easier and allow for complex and advance stuff not possible with current form of storage.

In term of implementation, we can cook the sql table and export it to be used freely across the plugin see

local db = sql:new(dbpath)
local workspaces = db:table("workspaces", {schema = {...}})
local projects = db:table("projects", {schema = {...}})

return {
    workspaces = workspaces
    projects = projects
}

local storage = require("storage")
local ws = storage.workspaces

ws:insert{ name = "Github workspace"}
ws:each({}, function(row) print(row.name) end)

I like this idea too. I think we should get all these ideas down and then split them into phases. We can get a basic implementation down, and then add more features.

Github projects are the best place to do that, we start by creating a simple notes, then convert them to issue for the release we aim to have them ready and then link them to pr. and close them with the pr. end-to-end.

Sorry, I'm not sure what you're suggesting here.

tbh, I forgot what I was trying to say ☺️

I think vim users tend to be okay with learning key commands, that we hopefully won't need a command palette, maybe we could show the available commands somewhere though or have something like vim fugitive's g? command.

Command palate are useful for discovering and getting used to plugin commands, later the user can choose what fit his workflow and bind mapping, but nonetheless is vital to new users.

have something like vim fugitive's g? command.

Serve the same purpose as a command palate, but the latter is better for actually getting what you want done.

claidler commented 3 years ago

Great to hear! Love the plugin so far and use it daily. Great to hear also! Some unclear questions for me of the proposal:

  1. How is the workspace PATH defined that one changes to?

I'm not sure what you mean? There isn't a workspace PATH, the individual projects have path's within the workspace's.

  1. Would workspaces then be defined as text file workspaces.txt inside $HOME/.local/share/nvim with project names and paths and workspace titles being distinct?

The projects names, paths, and workspace Id would be defined there, but the workspaces will be defined in a different text file. The projects will know what workspaces they are in. The workspace's won't know what projects they contain.

  1. How complex do you want this plugin to become? I would be against sessions to keep stuff simple. So far the telescope-projects.txt is nice and simple.

True. I'm really on the fence about sessions. It may never happen. I don't think it'd be massively complex, but it seems like it could be out of scope.

  1. Do you use harpoon? https://github.com/ThePrimeagen/harpoon It would be nice, if the format of stuff would be specified so other plugins can reuse the project information and to keep it simple. Probably even with the lua snippets how to read that information.

Use case for 4: Often one has shell stuff, which are reoccurring for tasks but not long enough or complex to justify cluttering the repository, ie something like watchexec -e rs 'cargo +nightly test --lib && bash tests/run_examples.sh && cargo +1.53.0 clippy &> clippy.log'. Would be nice to have a treesitter search for that, which can rely on the project information to execute the scripts in the proper project paths.

Yeah that's a good idea. I'll have a think on this one. Thanks!

claidler commented 3 years ago

Normal mode would be okay, insert mode, c-w is used often to deleted the previous word.

Good point. I'm looking to give people the opportunity to customise this. It's a real pain to figure out what's gonna work!

Wait so when the user clickc-1 he would launch telescope prompt with the projects in workspace 1? and yes c-0 to show all project make sense

That's right. It just filters them by the w1, w2, w3 .. w9 text.

well I've create sql.nvim for that purpose

I would love to use this and if this was a personal project I would as it would make my life easier, but I think people would be turned away by the extra dependency, when it's doing something reasonably simple... and there would be a concern about migrating the existing data to completely new data storage. It's in the back off my mind though. I'd probably have to do a survey on it or something.

Github projects are the best place to do that, we start by creating a simple notes

Great idea. I've been thinking I should probably use it. I'll get onto this soon. Thanks

tbh, I forgot what I was trying to say

That's me most days.

Serve the same purpose as a command palate, but the latter is better for actually getting what you want done.

Fair point, I'll reconsider! Thanks again