Version 1.0 - Please tell me what seems to be missing

[Canop]

broot seems to be ready to be labelled 1.0

Please tell me if you think something is missing for this milestone.

[kw-andy]

all good for me.

[Canop]

I intend to solve issue #65 before 1.0 (edit: done)

[Canop]

OK. Now there's absolutely nothing I want to do before 1.0.

[bstst]

I'd love to see sorting implemented.

By size mode seems to be implemented, but other sorting attributes should also be supported (eg last modified).

[Canop]

@bstst I think I'll make a whole sort mode, displaying only one level, but allowing in an obvious way sorting on date, names or size. Question is: should it be for v1.0 or a later version?

[bstst]

broot has been around for quite a while already and I'm the first one to request this feature — looks like people can live without it.

I suggest concentrating on v1.0 and postponing sorting to a later version.

[khaf]

Another sort idea is to sort by type, especially to show dirs first (sorry if this is already implemented, I haven't been able to find this) The default view installed by brew on MacOS does not show the trimmed trees, unless I actually start searching.

[ssendev]

When scrolling in sort mode it's possible to move the active column out of view by going up which selects the last item but doesn't refresh the view. the same happens when scrolling down and returning to the top item.

While scrolling down i would prefer if the bottom most item wouldn't scroll up so that empty lines are at the bottom but i guess there might be people who like it the way it is so maybe make it a config option. either way i don't think it would prevent a 1.0 release.

Another thing i had trouble with was that i wanted to see the unlisted items but couldn't figure out how to do that. Searching the issues i found #26 which mentions sorting by size can be used. With the mention of sort mode here i had the idea that selecting the unlisted entry and pressing enter could enter sort mode of that directory.

I also liked the hints for the verbs but i think they could be made even better when instead of just saying that e.g. Hit enter to toggle_hidden: toggle showing hidden files it could say in which mode it currently is.

[Canop]

Thanks for those reports. I don't reply in details right now but I note the problems and I'll think about them. Keep them coming!

[jcassee]

This might be out of scope for 1.0, as you already mention on Hacker News that it's not supported, but I immediately missed being able to search the whole path.

The interesting thing is, I think "classic" path search is not what I would want for broot. I'm probably mostly interesting in path search if filename search matches too many files. For example, suppose I type "dockerf" and I see a whole list of directories containing Dockerfiles. I then want to add search term to narrow the matching so I don't have to scroll down the list. Having to return to the start of the search expression is awkward. Instead, I would probably want to add conjunctive terms somehow to narrow down my selection. Does that make sense?

[Canop]

@jcassee yes it makes as much sense as it can. The thing with fuzzy searches anyway is that it's about heuristics, not about obvious specs. And yes I'll try to work on a way to improve filtering taking paths into accounts.

[fcpg]

It would be nice to be able to color some files by extension, like dircolors does.

[fcpg]

It could also be useful to filter (not sort) by date, Eg. "foobar <2d" to fuzzy match on foobar and only keep results newer than 2-day old.

[anotherchrisatwork]

To expand on @jcassee's request (or maybe this is new), I'd like to be able to search by path. Other fuzzy searches (like RubyMine's) let you type 'foo/bar/baz' to find the 'bazable.rb' file under the 'footronics/bartleby' directory. Again, wonderfully useful if there are a lot of 'baz' files below where you are, to find a specific one when you know where it is. I recognize that this conflicts with the regex-marker behavior of '/'.

I realize that you could search 'foo', hit enter to go there, search 'bar', hit enter, and then search 'baz', but again, there may be a ton of 'foo' files/directories, and so I would wind up using the arrow key a lot to get the one I want.

Absolutely BRILLIANT, by the way, that mouse clicks work! Thanks!

[Canop]

@fcpg

It would be nice to be able to color some files by extension, like dircolors does.

I didn't think about that. what would be the logic ? a map of colors in the conf ? Or do you think about a standard source ? Or just a computed colors only meant at ensuring different extensions are rendered differently ?

It could also be useful to filter (not sort) by date, Eg. "foobar <2d" to fuzzy match on foobar and only keep results newer than 2-day old.

noted (won't be for the 1.0, though, I think)

[benwhalley]

It would be great to be able to use the full list of matches in a verb. For example "/foo: rm" to delete all the foos, or even better, "/.txt:mv /text/" to move all the .txt files into the text directory.

[Canop]

@benwhalley This is something I'm thinking about. It's no so simple though, especially when the list of matches doesn't fit the screen

[benwhalley]

It's no so simple though, especially when the list of matches doesn't fit the screen

Yes - it did occur that it could be quite dangerous if it's a broad match into subdirectories. If you restricted it to regex matches then even if the list of matches is very long then at least the command line that results would be meaningful and possible to check before executing (and no more dangerous than just doing it manually with rm), but it does limit the usefulness.

[fcpg]

I didn't think about that. what would be the logic ? a map of colors in the conf ? Or do you think about a standard source ? Or just a computed colors only meant at ensuring different extensions are rendered differently ?

dircolors does it by associating an extension to a color, in a config file; simple, but somewhat repetitive.

I would let users define file types (eg text files, images, zips, bak files, RC files etc.,) by regexp and set a color for that type. Should regexp matching be too costly, just string-matching on extension would be better than nothing.

[evanjs]

Standardized shell completion files would be especially valuable for e.g. profiles managed by home-manager, where the .*rc files are read-only.

In addition, without standard completion files, the completion functions cannot be installed by the package manager, when other packages often make it as simple as copying a few files over (which is done during the installation process).

I was going to make an issue for this, but figured it might help to comment here, first.

[Canop]

I've created this new issue: https://github.com/Canop/broot/issues/140

because most of what's described here is interesting but shouldn't really be considered for a 1.0.

[Canop]

@evanjs see https://github.com/Canop/broot/issues/143 I'll probably make a first version today.

[dsvensson]

When leaving pager after view, it would be nice to get back to broot.

[axelsimon]

Here are a few small things i've found, starting to use broot:

• can't copy filenames. I have a long filename, i want to search for it elsewhere: none of the verbs allow me to copy it, straight to a clipboard, can't use file or even ls to just output the name of the file and then copy paste it, and trying to select the filename with the mouse cursor doesn't work either. Worst case, it might open the file, when i didn't want that necessarily.
• can't use page up, page down, home or end to navigate the list of files and directories on screen. So i'm stuck pressing my down arrow 15 times like a fool. Am i missing something here? Is the idea that one would always just start typing to search and navigate like that?
• rsync is not part of the verbs. Boo. Rsync is so superior to cp in many cases, it's a shame not to find a way to use it :)

Broot looks great otherwise!

[Canop]

Thanks @axelsimon for the report.

1) I hadn't understood the first point. Is it about pasting from the clipboard into the input ? If so an issue should be created to remember me to implement it

2) pressing the down arrow 15 times isn't really usual as you most often fall on the right line just by searching and your page is normally short (not trimming root isn't the default and should probably not be). You can also jump to start or end of list. If you want another way to navigate (5 down ?)

3) the idea about verbs is that you define the ones you want. You may define rsync like this:

[[verbs]]
invocation = "rsync {dest}"
execution = "rsync -avz {file} {dest}"
leave_broot = false

documentation

[Ckln]

Hello @axelsimon, concerning this point

• can't copy filenames. I have a long filename, i want to search for it elsewhere: none of the verbs allow me to copy it, straight to a clipboard, can't use file or even ls to just output the name of the file and then copy paste it, and trying to select the filename with the mouse cursor doesn't work either. Worst case, it might open the file, when i didn't want that necessarily.

my solution is usually using the :print-tree verb (default shortcut :pt) which will leave broot and print to the console what broot was displaying. From there you are free to copy easily. In my case it is usually enough but if you don't want to leave broot it is not ideal.

You can in this case create a verb to ls the file, as shown in previous post by @Canop.

Hope this help you enjoying that great tool :)

[axelsimon]

Thanks for such a quick answer!

Regarding 1: using broot, i've navigated to a directory on computer A and found that a specific file is there. Now, i want to search for that file on another computer B (over ssh, for instance). I want to copy the filename of the file on A and use it on B without having to retype. Or to search the filename on the internet. If it's long, i don't want to have to retype the file name manually (and i shouldn't, as that's prone to error). Currently, once you've found a file using broot, there is no easy way that i could see to copy just the file's name. Does that make more sense?

Regarding 2: i guess i'm not using the search enough, as i've just started using the tool. However, if i can see that what i want is the last item of the list, hitting is nearly always going to be faster than typing the name of whatever the last item of the list is. I'm not sure what you mean by "You can also jump to start or end of list."

Regarding 3: looks great, i'll try! thanks!

[Canop]

1) It looks like :pt might be what you need. You may also be interested in composing the output of broot in the ways described here: https://dystroy.org/broot/documentation/tricks/#dcd-deep-fuzzy-cd

2) you can map the :select_first and :select_last verbs to keys of your choice in the config file

[axelsimon]

Thanks a lot for these answers. Helpful stuff! :) I'm experimenting with creating my own rsync verb and it's both fun and useful.

One thing that i have found is still a bit annoying: when completing a command line, for instance "mv foo /home/axel/Documents/bar" there is no way to use auto-complete to complete the destination path. This means typing in the entire destination path, which can really be quite long. Any plans for auto-completion there?

[Canop]

Any plans for auto-completion there?

I'm working on it

[Canop]

Bunch of things have been done. A short review of what was mentioned here:

@bstst You can now sort by size (:ss), by last modified (:sd), by deep count of files (:sc) @evanjs standard shell completion files are included in the distribution @axelsimon tab based auto-completion is available @dsvensson now, when a terminal application is launched with leave_broot=false, you get back to broot after quitting the app @jcassee @anotherchrisatwork There are several filter types now, including searching subpathes @fcpg it's possible to link colors to file extensions

[Canop]

broot 1.0 is out. I close this.