Wow. Thank you. As an open-source author it really helps to get this kind of comments.

Please accepts my sincere congratulations and appreciation for your work on broot too! (Et bonjour de lyonnais à lyonnais pendant qu'on y est!) And I see you work for this french group now, and I'm pretty sure one of my plant management software is deployed at one of their plants - the world is small!

Hey, come tell me more in my virtual coffee room : https://miaou.dystroy.org/3?Code_Croissants

Well, here’s another one - this is easily one of the most useful cli tools that I’ve installed in a very long time. This is amazing work!

Thank you! I really like your program.

Open source authors should be getting more "thank you" messages rather than constant barrage of issues and complaints :)

Have an excellent day and successful year!

It never occurred to me before, but it'd be great for GitHub et al to have a way to leave kudos and thank-you notes. As things stand, the only affordances are for leaving issues and complaints, so it's not surprising that that's what get left.

When devs give a link to their twitter account, their chat, etc. they certainly wouldn't mind reading a kind personal comment from time to time.

I'd be happy to use a first-party system designed for simply saying why I like something. However I'm not willing to create a Twitter account just so I can thank someone when we've never met (and likely never will), and are likely never to speak to each other again. Same deal with signing into other services through GitHub (like gitter), that might start sending me emails (when signing in via GitHub, the service gets your email address; so far as I know, gitter doesn't use it for anything, but other services might).

I’ve seen and used issues as “thank yous”. As a developer, I don’t mind this misuse of the issues :-)

I've done that a few times, and always felt anxiety before hitting "submit". So far I've had mostly good reactions to it, but I've also had it ignored and the ticket silently closed.

Devs could allow a "this software is too good for us" issue, keep it unresolved and see how many would pile on ...

(A really cheeky issue tracker could have this built in as issue 0.)

Ignored and silent closed is not the same as negatively commented on and closed.

Thank you issues while clutter would be my favourite off topic issue to close.

Probably depends on the person. I would kinda mind that.

Isn’t that what stars are for? Not a note, but I wouldn’t Star a repository I didn’t appreciate.

Unclear, I think. I tend to use GitHub stars as bookmarks, which implies interest but not necessarily hearty approval.

I don't think you can generalize here; it's like Twitter, where some people use Likes to remember all-time favourites and some people use them as an "I've read this" checkbox.

I also use stars as bookmarks. A dedicated "appreciate" button would be nice.

F

Besides the thing sibling commenters mentioned about GitHub Stars acting like bookmarks, I also feel that GitHub Stars are more intended to be used to indicate interest in the source code itself—which is a bit different from indicating interest in the product you get by compiling said source code.

I might Star e.g. Postgres (yeah, I know, not their official repo) because someone told me that it's an example of good, elegant code, and I would like to study it. But that doesn't mean that I'm a Postgres user, let alone an adoring fan. I'm starring the code.

What a great idea! I submitted it to Github's feedback form.

The new GitHub Sponsors program is great for donating to an open source author but it requires the author to sign up.

I could have sworn that GitHub's "emoji reactions" thing applied to a repo's Releases, but I guess I was mistaken. It'd be a nice addition.

Stars?

Doesn't feel personal enough. It would be helpful to be able to express what you like about a piece of software.

That's what I use stars for anyway.

Let me pile on btw: great tool!

Just installed it. It looks nice. It's great to see that there is room for improvement for the shell commands and utilities we use everyday.

I think a vim mode would be great. The first thing I did was to use 'j' to navigate in the tree.

Strongly agree. Keyboard interfaces can be very fast and efficient, but their weakness is having to learn a separate keymap (or set of options) to use a new program.

Vim keys is the closest console programs have to a common language! I seriously think all console programs should use a vim-like keymap. Not Emacs, because Emacs has a completely different philosophy - integrate everything into Emacs. Emacs is the prototype IDE. Emacs doesn't seek to export its keybindings, it seeks to import everything.

The problem with using "j" to go down is that it prevents you from using "j" to filter files having a "j" in their name.

Presumably a vim mode user would jump straight to `/` to filter, or i/a, or f{letter}, etc.

That was first thing I did - check if I can navigate vim style. However it has different philosophy. It has fuzzy search, so that you just type name of directory which you want to enter, it will be filtered out and hit enter. Now you can explore it.

A couple of programs substitue that with ctrl+[hjkl].

You can define your own shortcuts for navigation. See for example this: https://github.com/Canop/broot/issues/24#issuecomment-572481...

Same. It seems like it could be useful, but I'm virtually handicapped after decades of vim mode in a sense I cannot efficiently use any software that doesn't support vim keystrokes (well, nobody really can, they just don't know that).

I did the same thing. A vim mode would be a nice addition. To search for j, I think creating an insert mode would be best.

Better `/`. It is already default in dozens of programs with vim-like layout, including as prominent ones as man, less, ranger and more.

I too agree with strength that is strong. Just yesterday I was googling how to get tree to respect my git ignore. The universe heard and responded with broot!

But without first class support for vi navigation, be will end up replacing tree as my directory preview pane in vifm.

I second this. This has replaced nnn for me and solves so many devops headaches. Excellent work!

This should teach anyone that tackling something that's considered "the basics" is not a bad idea. It is astounding how these really simple things can still be enhanced (or even revolutionised ;)) in 2020.

> This has replaced nnn for me and solves so many devops headaches

Can you please elaborate? Is that specifically because nnn[1] doesn't show a complete overview of the filesystem or some other features are missing?

One of the guiding principles of nnn is to generate minimum disk IOs.

Reading through a complete volume on a stuffed microSD or SD card attached to a RaspberryPi to list the filesystem (even if compacted) and then supporting filesystem changes dynamically is resource-intensive. nnn development is driven by minimum resource availability and usage.

[1] https://github.com/jarun/nnn

You know, I hadn't considered that. This distinguishes nnn from Broot. I would revise my comment if I could, but in the absence of that ability, consider this my correction.

No problem! Just wanted to get some insight and explain things as they are with nnn.

A new version of nnn is released - https://github.com/jarun/nnn/releases/tag/v2.9

It simplifies a lot of workflows and reduces the number of keys.

Could you elaborate which devops headaches got solved ? :)

At the risk of embarrassing myself: The ":s" verb for easily viewing the size of directories / files, the overview of multiple directories at once, the gitignore handling, at a glance. There might be more, but I would have to spend more time with it.

disclaimer: my definition of "devops" is sitting in a remote terminal for where I run docker and chasing down which files take up all my precious space, or not remembering where I put something, which makes the tree overview very useful. I know I could achieve this via many other means also (and did before Broot), but Broot is also very pretty, so I quite like that, too :)

> The ":s" verb for easily viewing the size of directories / files

It's the keybind "S" with nnn (or "A" for apparent usage). You can also use the same option ("-S") to open nnn in du mode.

> the overview of multiple directories at once

I explained the nnn design strategy in my other response

> the gitignore handling

This can be added but it changes the current generic way of handling directory entries

> There might be more, but I would have to spend more time with it

That would actually be a constructive data to improve nnn as well.

Thanks for the notes!

No worries. I wish I was able to give better feedback, but I am nowhere near as expert a user as many others surely are.

I like how 'on the ball' you are with this though, it's that kind of passion that makes projects like nnn so strong!

Yep, great ideas are always welcome! There's always room for improvement.

+1 I use a combination of Linux tools all day to achieve this: ls, tree, ranger, ncdu. Thanks so much for writing a tool built primarily for directory exploration. This deserves to ship in Ubuntu ASAP :-)

#1 ask: please add a Vim mode for j/k navigation and / search.

It's funny that it is called Broot and a bunch of people just downloaded and ran an executable from the internet.

I am Broot, and root, on so many computers now !

but seriously, how to install from source is clearly shown

+1, I completely agree!

Especially the screenshots help to get motivated to try it and if you try it you will notice it just works as advertised - awesome :-D

I can't agree more. I don't understand why other software developers think (or don't care) that it's okay to have tedious installation instructions and or controls. I'm a developer and I want to get my new tool and start playing with it, not spend hours with configuration and setup.

what's the easiest way to install it on Mac OS? I don't see mentions of a brew package in the doc.

brew install broot

then run the broot command and it will prompt you to update your .bashrc or .zshrc file

Both `brew install broot` and `cargo install broot` work (latter if you have Rust installed, which is just `brew install rust` away).

The homebrew version is quite behind though, it was 0.10.x when I checked earlier today, while the latest version is 0.11.x.

There are install instructions for cargo, so it's Rust. Install those prereqs first and then use cargo to install Broot.

I was unable to cagro install it, had a bunch of build errors. Decided to brew install it instead, and although its a major version behind the github release, it works as advertised!

Looks like rust/cargo but i haven't tried it yet

Great summary!

This is an awesome piece work. Do a "simple" thing extremely well! Well done