[Request] Add a way of tracking and easily cd-ing into your most used directories

[pakoito]

Did a discussion occur before? I am not on Miaou, and I'm not confident with a "hi everyone" as I am doing it here

Is your feature request related to a problem? Please describe. No

Describe the solution you'd like There are several tools to tracks your most used directories. In my case I use https://github.com/rupa/z. This is useful when I'm doing long jumps to folders whose path I don't even remember or I worked on only a few times. z keeps track of them and allows me to jump based on a guess, so instead of cd ~\Coding\java\project\src\main\com\bla\mypackage or the equivalent using broot, I can do z mypa and it'll take me there directly.

Describe alternatives you've considered dcd only searches in folders inside the current one. I can invoke z from outside, I thought it'd be good to bring the functionality inside too.

Additional context

[Canop]

Any idea of how you would like it to work functionally ? Manual addition of favorites or automatic one ?

[pakoito]

The way Z does it is automatically. It takes over parts of your shell and keeps a list of paths alongside their frequency and last access time, then uses that for a fuzzy search and takes you the top ranked on enter, and a list of matches on tab. If the path is new it wouldn't find it.

λ Pacos-MBP ~ → cat .z | wc -l
     155
λ Pacos-MBP ~ → cat .z | rg arrow_typeclassless
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules|11|1574856388
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow|2654|1594119589
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/core/arrow-core|3|1529756392
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/core/arrow-syntax|6|1529759238
/Users/paco/Coding/Kotlin/arrow_typeclassless|8|1588640763
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/docs/arrow-docs/docs|2|1529777459
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/docs/arrow-docs|16|1574856352
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/optics/arrow-optics|4|1529759351
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/core|6|1533502031
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/core/arrow-mtl|3|1533069610
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/core/arrow-typeclasses|6|1529756425
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/docs|1|1529759669
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/docs/arrow-docs/docs/_data|4|1529759615
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/optics|2|1529759245
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/docs/arrow-docs/docs/docs|2|1529777457
/Users/paco/Coding/Kotlin/arrow_typeclassless/arrow/modules/core/arrow-data|2|1529757390

My suggestion is to keep this list for paths where you cd to, rather than expand.

[emmanueltouzery]

ultimately, it would be enough to:

• allow executing configurable commands when broot changes folder (so the most used directory list can be updated) -- can be fully async and delayed
• allow broot verbs to return folder paths (through echo/printf) and then broot would jump to that folder (so the user can invoke the app/script to return to a most used folder, based on user input, and broot would navigate there)

[Canop]

@emmanueltouzery Those additions seem possible

Did you see this alternative: https://github.com/Canop/broot/blob/master/client-server.md ?

[emmanueltouzery]

thanks for the answer! I didn't notice that, but in the end adding the features to broot actually seem simpler than leveraging this. Because we'd need either one server for all the broot instances, or one for each instance.. it seems like it could get quite complicated.

[Canop]

@emmanueltouzery If you think you would really use this pair of hooks, can you create a separate issue asking for them ?

(sorry, but I'm a little too used to people asking for a change then never even trying to use it)

[emmanueltouzery]

you're thinking correctly: honestly I cannot guarantee I would use the feature. I also don't feel comfortable asking for that work of you, that's why I wanted to rather comment on an existing issue. At this point I'm only looking at broot, not using it actively. I just wanted to limit the scope of this bug, which seemed huge at first. If there is not much demand for this, it could make sense not to implement this yet.

There may have been a misunderstanding, but when I wrote "adding the features to broot actually seem simpler than leveraging this", I wrote it 100% from my point of view (writing a socket server or adding the features to broot, both from my pov). I'm not excluding trying to add the feature to broot myself, if I find some time -- and that would be the best proof to you that people really want that, if I do it in the end :)

[Canop]

There was a "if" in my previous comment, it's ok to give a technical opinion without really willing to use something, don't worry. And your idea is still interesting.

[Canop]

A note to everybody: the reason I didn't rush for this whole feature is I feel most users wouldn't need it anymore after getting used to broot: you usually go to where you want with a very short number of keystrokes with a broot fuzzy search anyway.

[emmanueltouzery]

this last comment was a consideration for me too. i did some "benchmarking". starting from my homedir, I tried two folders I had in mind. normal fuzzy matching wasn't useful from the homedir, too many false positives. Regex was too slow. Using e/xxx exact matching gave by far the best results.

in one of the two folders, broot native took possibly 100-150ms to find the folder i was interested in (feels like something like that). in the other case, a deeper-nested folder, broot takes.. maybe about 1.5s? It's fast of course, but far from instant. But I wouldn't expect it to be, starting from the home dir!

It stands to reason that just iterating a list of folder names in a flat file is going to be massively faster than exploring the filesystem, even with today's super fast IO.

Basically, if I ended up using broot+z, I think I would use broot searching within a project... and z between projects (in which case broot would need to search my whole homedir to compete), or maybe for locations I go to very often within a project. In the end this could be solved with "bookmarks", but the z approach is the lazy one. Basically you get self-organizing bookmarks, for a very fast jump anywhere on your filesystem, without having to manually manage such bookmarks.

[Canop]

@emmanueltouzery I could answer but this would be very chatty. Could you come to Miaou to discuss that ? https://miaou.dystroy.org/3

[emmanueltouzery]

I'll try this evening

[evanescente-ondine]

Indeed browsing through the filesystem is far from instant, I noticed it too. Searching through a whole library of books would be nigh impossible. Especially since I don't have a SSD. Ideally, linux/mac would update a database of all directories, and index their contents automatically at the same time. and allow for view of relational databases as temporary directories... we're in 2022, dammit...

[Stargateur]

Ideally, linux/mac would update a database of all directories, and index their contents automatically at the same time. and allow for view of relational databases as temporary directories... we're in 2022, dammit...

Do you refer to the nightmare feature of windows, scanning every bit of hard drive, ruining perf and longevity of disk ? Anyway, this idea is not simple and not the job of an operating system.

[evanescente-ondine]

Granted, the implementation is often (always) bloated AF. I rather thought of something simpler. I'm certain there could be parameters to consuming all resources like recoll-index do constantly. Be it music, configuration files, pdf or text files, I don't change them every second, rather a few times per day. So why can't there be a quick routine associated with the file system, to do what I describe effciently ?

[Canop]

It's quite easy (for a rust programmer) to add some filtering engines to broot and some of them can use external indexes. I made for example a filtering engine based on ballish - I discarded it as there was no real point for SSD users.

But please @evanescente-ondine don't squat unrelated issues, it makes them harder to manage.