silicakes / zellij-sessionizer

Quickly navigate your file system and start a zellij session instantly!
MIT License
10 stars 2 forks source link

API: depth of search and list of paths #4

Open amtoine opened 1 year ago

amtoine commented 1 year ago

As for the depth part - lets talk about it. Perhaps we'll need to support some kind of arg passing i.e zellij-sessionizer --depth ... --paths.. or perhaps setting up some global variables instead, like:

ZELLIJ_SESSIONIZER_PATHS=...
ZELLIJ_SESSIONIZER_SEARCH_DEPTH=...

But this will be outside the scope of this PR, so we can merge it regardless!

Originally posted by @silicakes in https://github.com/silicakes/zellij-sessionizer/issues/2#issuecomment-1594827118

amtoine commented 1 year ago

@silicakes as you said, this was quite out of the scope of #2, so i thought we could move into an issue :yum:

amtoine commented 1 year ago

maybe the simplest would be to

i'm super rusty in Bash, so i'll give an example in Nushell :relieved:

see here actually this looks quite good :open_mouth:

i can't wait to mix that with my nu-zellij :open_mouth:

silicakes commented 1 year ago

maybe the simplest would be to

  • take a list of paths
  • propose them directly as the possible options to attach to
  • or search inside them recursively when a depth is given

i'm super rusty in Bash, so i'll give an example in Nushell 😌

see here actually this looks quite good 😮

i can't wait to mix that with my nu-zellij 😮

From what I gather, we're basically talking about passing on depth. How about we go a step deeper and just collect any argument flags, normalizing it for find/fd and providing our current values as default, i.e:

# I prefer find's argument style as you type less
$ ./zellij-sessionizer /dev/null ~/dev --maxdepth 2 --type f --other args

Then we just normalize the thing into something like

if fd
  fd max-depth $maxdepth || 1
else
  find maxdepth $maxdepth || 1

Don't think about the implementation details for now, think about the user experience.

amtoine commented 1 year ago

Don't think about the implementation details for now, think about the user experience.

agree :+1:

tbh i think we could even take the find part out of zellij-sessionizer :thinking: if we assume the goal of zellij-sessionizer really is only to sessionize, we could even go this full route:

gm list --full-path | zellij-sessionizer.nu
# or
zellij-sessionizer.nu (gm list --full-path)

Note i manage my Git repos with a command called gm and gm list gives the list of all my Git repos :+1:

that way, we do not even have to search for anything inside the sessionizer :open_mouth:

silicakes commented 1 year ago

Don't think about the implementation details for now, think about the user experience.

agree 👍

tbh i think we could even take the find part out of zellij-sessionizer 🤔 if we assume the goal of zellij-sessionizer really is only to sessionize, we could even go this full route:

gm list --full-path | zellij-sessionizer.nu
# or
zellij-sessionizer.nu (gm list --full-path)

Note i manage my Git repos with a command called gm and gm list gives the list of all my Git repos 👍

that way, we do not even have to search for anything inside the sessionizer 😮

I see your point, but we're not just about git or repositories although the case is quite common. Similarly to zoxide, we just want to streamline navigation and adding zellij to the mix

amtoine commented 1 year ago

I see your point, but we're not just about git or repositories although the case is quite common. Similarly to zoxide, we just want to streamline navigation and adding zellij to the mix

oh yeah, i agree :+1: gm list was a concrete example, but we could have something more general with

fd . <path> --min-depth 1 --max-depth 2 --type d | zellij-sessionizer.nu

the goal of my thoughts here is to have something very free of choice from the user end point and it has the advantage of relieving the sessionizer from a bit of its complexity :yum:

silicakes commented 1 year ago

If I understand what you're saying, essentially zellij-sessionizer will only pick whether you're inside zellij or not and will choose whether opening a new pane or attaching into a session?

did I get it right?

P.S someone doesn't care once being inside zellij or not, they can just make something like:

cd $(fd ... | fzf) | zellij -- session $(cwd | basename) -c
amtoine commented 1 year ago

If I understand what you're saying, essentially zellij-sessionizer will only pick whether you're inside zellij or not and will choose whether opening a new pane or attaching into a session?

did I get it right?

yup, that's the idea + fuzzy finding the desired project with things like fzf :yum:

silicakes commented 1 year ago

I prefer it to be a zero config thing, or at least striving to zero config. I don't want people to writing scripts which sole purpose is to make zellij-zessionizer work. That's why I started this thing to begin with:)

Does this makes sense?

amtoine commented 1 year ago

I prefer it to be a zero config thing, or at least striving to zero config. I don't want people to writing scripts which sole purpose is to make zellij-zessionizer work. That's why I started this thing to begin with:)

Does this makes sense?

by zero config, do you mean having to list the paths outside of zellij-sessionizer?

if yes, i'd say it'd be great to allow both :+1: i.e. allowing to pass precomputed lists of paths, e.g. with ghq list or my gm list --full-path and allowing to recursively search for directories in another given as parameter

would that be a nice middle-ground? :yum:

amtoine commented 1 year ago

i tried something just in the middle, allowing both behaviours, #7 :pray:

silicakes commented 1 year ago

I'll take a look soon, and will add it to the sh version too before merging

amtoine commented 1 year ago

I'll take a look soon, and will add it to the sh version too before merging

great no pressure :relieved: and feel free to say if you do not agree with the direction i take or if it's unclear what i'm doing :wink: