Closed claidler closed 3 years ago
I would really appreciate any thoughts/ideas/suggestions - related or unrelated, ordinary or insane
😍 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.
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 thew1...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).
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:
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:
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.
Great to hear! Love the plugin so far and use it daily.
Some unclear questions for me of the proposal:
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?
telescope-projects.txt
is nice and simple.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.
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.
Great to hear! Love the plugin so far and use it daily. Great to hear also! Some unclear questions for me of the proposal:
- 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.
- 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.
- 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.
- 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!
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
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
ctrl+1
...ctrl+9
will open workspaces 1-9 (it's capped at 9, would people want more than 9?)ctrl+0
is the default, which shows all projects across all workspaces.ctrl+w, m, 1
move project to workspace 1 (read as ctrl+workspace, move, 1)ctrl+w, d
delete project from workspaceI'm not sure about the key commands yet - I just plucked them out of thin air.
The dev's guide
w1...w9
.w1...w9
for the specified project.