Show HN: tere – A Faster Alternative to cd+ls (github.com)
Hi HN!
I wrote a small program to browse folders in the terminal. The main inspiration was type-ahead search in GUI file managers. There exist several programs that are similar (see the listing in the README), but none of them do it quite the way I like, and often they have a very complex UI and a ton of features. I tried to make something that is obvious how to use and gets out of your way. (I also wanted an excuse to learn Rust.)
Let me know what you think!
205 comments
[ 6.2 ms ] story [ 297 ms ] threadOn qwerty I think that's the case :)
crossterm = "0.24.0"
dirs = "4.0.0"
regex = "1.5.4"
serde_json = "1.0"
serde = { version = "1.0", features = ["rc"] }
textwrap = "0.14"
unicode-segmentation = "1.7"
I guess one could write their own textwrap and probably also dirs, but other than that they all are probably vital to this tool.
The only reason this wouldn't be a problem in another language would be because that language already includes the functionality of such libraries
Having over fifty dependencies for something like this is not in any way terrifying—you’re just starting with a different set of expectations and understandings of how things are done. It’s a natural and reasonable outworking of (a) using the right tools for the job, (b) doing things properly rather than half-heartedly (most obviously where terminal interactions are involved), and (c) Rust’s deliberately thin standard library.
Writing in Rust looks like casting spells in an Infocom game.
Gnusto rezrov!
https://en.m.wikibooks.org/wiki/C_Programming/stdlib.h/itoa
I get the others, but that ones a pretty standard type converter, the opposite of the C standard atoi
Different tools for the same job. One is explicitly integer to string conversion the other is sting formatting.
You can technically use the latter, but some prefer a function which explicitly does one thing and one thing only.
C kind of gets a pass for this stuff because C was old and in the early days they were limited by token size. But to still be using this term today in a new language seems fairly derisible.
Assuming you get it working at all.
I don't think it's an inherent feature of scripting languages that they are hard to distribute. I'm pretty sure it's possible to package up a tiny Lua interpreter (or e.g. QuickJS) and all necessary scripts into a standalone file.
Reminds me of the idea regularly pushed here that you need a virtualenv even for thirty-line scripts. I read these kind of takes here often and am a bit baffled by them. Maybe it is because developers have lost administrator skills over time, that this feels like an insurmountable challenge?
Don't forget the startup time overhead of first loading a whole interpreter into memory, then loading a python program into the interpreter.
Granted, a few of these things apply to Rust stuff as well (e.g. resources and manifests can’t quite be done out of the box without extra tools), but most of them are inapplicable, and the remainder tend to have better solutions than I observed in Python-land. And a lot of the pain that I’m describing of the Python stuff isn’t that it’s hard to do anything, but more that I’ve found it all just exceptionally error prone and unreliable.
Is that really all that different from Python?
> Because of Python’s conservative nature when it comes to backwards-compatibility, when a module is added to the stdlib its API becomes frozen.
So it sounds like they do do something fairly similar, but just a different mindset on adding libraries
You can do a lot with pythons stdlib, and a lot of popular libraries (requests, for example) largely are just usability wrappers for underlying stdlib stuff.
Whereas with Rust, you have a very minimal std, and things you want to achieve are imported specifically.
This is the sort of thing that I meant by “doing things properly rather than half-heartedly”. You could make something like this by reimplementing half the libraries in an inferior fashion, full of bugs, cross-platform inconsistencies and missing functionality. Or you can take an extra dependency. Even in Python, the recommendation would be firmly to add dependencies like appdirs for dirs and I dunno what for the rest.
But you're right that it could always be simpler, in fact I wrote tere originally in C with curses as the only dependency, and it compiles >10x faster. But there I had to manually write some (pretty certainly buggy) unicode handling, and I think adding extra features (proper arg parsing, json for history file etc) would be way more painful.
With rust you just check in your Cargo.lock file to your VCS and then the versions of your dependencies and their dependencies (etc) are pinned, so if it works now then it will always work. For dependencies on crates.io authors don’t even have the option to remove a version once it’s published.
Upgrading dependencies is an explicit operation, so you only do it when required and run your tests afterwards.
In practice I’ve had far fewer issues with dependency versions using rust than I’ve had using dynamic system libraries in the C/C++ ecosystem
As long as the use of dependencies remains reasonable, the number of dependencies does not immediately mean that the code is "bloated".
The answer to your question "How come a simple thing is more complex than I first thought?" is: "Because you've spent less time thinking about it than the author".
Whether this is better or worse seems to be a matter of contention for a lot of people, but it certainly poses a challenge for supply-chain auditing. I suspect for Rust to truly ever replace C++ in its domain, the ecosystem is going to need to come up with something like boost so you can grab one library that does all the things nearly any program wants (regex, serialization, cli opts, etc) but that don't get included in the core language's stdlib.
Yes, but then you are stuck with glibc + kitchen sink and GNU code quality, which is atrocious.
Musl is far superior as a libc, but most Linux software is written for glibc and has quirks that make porting hard.
Nope. It’s better at some things but with so many caveats that this is just dumb to claim.
Anyway, GLibc is just better, both in terms of performance (algorithms are more optimized, at the cost of a bigger executable size) and in terms of available features.
Not only for that. As much as I love copyleft, I'm really happy that musl exists so that I can easily test my programs locally for portability. Compiling stuff with different compilers and libraries exposes at once all sorts of weird bugs before you get to publish your codes.
The comment I replied to is less than 100 characters long plus a command line invocation.
One of these two has spent more time thinking about whether some dependencies are needed.
And unless you're actively developing in Rust, why would some other people's choice of naming their projects in a language and tool chain you don't ever plan on using be such a big deal?
I'm not saying that there should be some kind of totalitarian regime that enforces naming, I'm simply saying that yeah it kinda sucks that Rust devs tend towards cutesy names over ones that convey functionality.
This just seems like you're getting weirdly offended for no reason. Not everything is some kind of attack on individual agency. There is absolutely nothing wrong with me remarking on the state of Rust naming. The fact that you are conflating it to be a "big deal", which I never said it was, just seems like bad faith arguing me. This is just not something to get so offended over.
Are you using Rust? If not, why does it matter what they choose to name their libraries. This is my entire point, you're coming in as an outsider criticizing something that is clearly not a problem to Rust devs.
If actual Rust developers are using them to the point where they're popular enough to gain (unwarranted, imo) criticism, then clearly they're working, silly name and all.
It's almost as if people care more about what the function a package provides rather than its name.
You've hyperfocused so much on my "criticism of your criticism" and the permissibility behind it that you chose to ignore the actual criticism I laid down.
I'm not continuing this either way since I've said my piece. Maybe step back and actually read my comments rather than focusing on me criticizing your critique.
Also, pot calling the kettle black. You spent an entire comment being offended over my critique.
Also it isn't a criticism of my criticism, it is an assertion that I should not be allowed to criticise at all, which is a totally different thing. Of course I am going to call that out
EDIT: I can't reply because rate limited
Please calm down. I'm not threatening you. I'm simply surprised that you make such inflammatory and aggressive comments on an account that is so closely tied to your professional life, that is all. I think you should reconsider doing so
I never said you can't criticize. As the other commenter already said, you're allowed to critique but don't be surprised when your criticism is then critiqued itself. That's the epitome of modern discussions and debate.
I gave you examples of what you can do right now, aka making your own alternative packages, but you chose to ignore that all and double down on "don't you dare critique my criticism".
And then (I'm going to point this out again because it's so absurd) vaguely implied my comments would face professional retribution. Because I chose to disagree with you and make that public.
In any case, I said I'm stopping and I am. You should too, as you're already crossing several lines with this comment.
This is exactly cultish thing about Rust, that unless someone is praising Rust, they are free to keep their mouth shut.
Nobody said that. Of course you can criticize. But be aware that your criticism itself could be subject to criticism.
https://trends.google.com/trends/explore?date=all&geo=US&q=s...
Sure, it could be named serde_framwork and serde_json, but I think serde and serde_json isn't that bad either.
That's what I mean when I say Rust community is toxic here https://news.ycombinator.com/item?id=32105449
For context, I totally agree that rust often ends up with more dependencies than I would like and that crate names are often super unhelpful, but I downvoted the comment.
I recommend either CBT or writing your own version with fewer dependencies to ease your terror.
The deps for each of these packages is really out of the authors hands, this is really the same for any programming language though which need to pull in dependencies of their own.
Essentially the same UI.
I do think your program does add some features not found in VIM.
Also netrw is a bit of a mess; I once found a bug and thought "I'll write a patch". After five minutes of browsing through the code ([insert Eddie Murphy meme]): "yeah, never mind".
Later i "upgrade" it to a Star Trek LCARS Design.... i have to look if i still had the sources.
History repeats.
I really thought it was initially a typo on "tree" (the tool's purpose is to navigate the folder tree) that the author decided to keep.
”Tere” is also, perhaps unsurprisingly, used in Finnish.
autoload -Uz compinit compinit
zstyle ':completion:*' menu select
Then ‘cd <tab>’
In the demo, how did you get the key press indicator to show? I haven't seen that before, but it's a wonderful addition. And may I ask what you used to record it?
I used screenkey to display the keystrokes and Peek to record the gif. I actually wrote some instructions for myself so I remember how I did it if I want to update the gif: https://github.com/mgunyho/tere/blob/master/demo/README.md
Very well executed.
I'm not sure there's a level between fifth and "being obnoxiously pushy," but if there's such a thing, I'd be interested to know. :)
I find these kinds of text based, keyboard centric explorers to be far superior for navigating around a codebase, then giving you back your screen space as soon as you're found what you're looking for.
I implemented something similar but for VSCode: https://github.com/danprince/vsnetrw
Once I select a directory I want to dump myself back out into a command line in that directory, I couldn't see the key for that? Or am I misunderstanding the purpose?
I'll add ~ as a shortcut for the home directory, thanks for the good idea! (It conflicts with type-to-search for folders starting with '~', but I think that's much less common than cding to home.)
https://youtu.be/2l7cIc4INAs?t=89
The auto-cd can also be turned off with a CLI option.
Which was seemingly addressed as well, no?
I think the word you are looking for is “indirectly”.
I think you're underestimating how efficient your brain can get at guesstimating how many characters are required to navigate to a directory, especially when the directory structure is familiar (at which point I virtually never overshoot).
And, I still find value in this feature despite being a fast typist (90 WPM).
[1]: https://github.com/junegunn/fzf#key-bindings-for-command-lin...
> I also wanted an excuse to learn
This is the best reason ever, and not just for you: seeing your GIF I thought "could I achieve that with fzf?". Turns out, yes I can:
Certainly not the best code (and definitely not a jab at your implementation!) but, hey, it was purely for the heck of it.Lately I've been trying to find the joy in programming again, these kind of fun little challenges help a lot, so thanks for sharing, enthusiasm and creativity is contaminating :)
While digging up alternatives (of course after I had already written most of the functionality), I briefly tried out fzf. I think at that time I couldn't find an example snippet like yours to do the cding, so I didn't look into it much more. With some basic settings, it was also not easy (or even possible?) to go up in the folder tree, but I see that your example handles that.
If you're unfamiliar with a big folder tree, fzf (or another very similar tool that is designed for this purpose, broot) can be more efficient. But it might take a while for it to scan all subfolders.
Well, fzf is only a selection tool, it's more about the tool that feeds fzf data ;) That's why I used a dumb ls in my example. Maybe a difference with yours is that it does perform cd on each loop, and there's no way to bail out and not cd.
> it might take a while for it to scan all subfolders.
Haha yeah, for recursive cases I was using ripgrep as fzf default command:
And now I just discovered fd[0]: (...at least essentially, my setup is a bit more tunable and complex, I have a few of these with varying flags depending on the situation and goal)[0]: https://github.com/sharkdp/fd#using-fd-with-fzf
I've been sporting this alias for a while now:
You can run `pf` (preview file) in a directory and it opens a split window with fzf where you can preview text files with less and optionally filter down which files are matched with fzf.fzf is great.
If you're using the fzf.vim plugin[0] you can run `:Commits` to do something similar to your command too. It adds a bit more detail such as when the commit was made in relative format and color codes the git diff.
[0]: https://github.com/junegunn/fzf.vim
The best one I've seen recently was a fellow enthusing about the descendant of Plan 9 who wrote, "I'll always singe the praises of Inferno!".)
bind -x '"\C-p": cd "$(dirname "$(fd | fzf )")"'
https://github.com/antonmedv/llama
But with fuzzy searching.
I also submitted few days ago here on HN: https://news.ycombinator.com/item?id=32081263
To compile it, I had to sudo apt-get install libacl1-dev, which was not mentioned in the instructions.
Ideally, I would provide pre-built packages from CI, of course.
Also typical hacker news - "why don't you just use Vim"? Ha. Ignore the naysayers.
BTW, checkout `nnn` search-as-you-type and cd-on-quit features. I think its similar in scope to this project.
https://github.com/jarun/nnn
https://github.com/jarun/nnn/wiki/Basic-use-cases#configure-...
For example
It has more or less the same UI as the one in this Show HN but with the added feature of opening any files you select.That said, I do think your reply here is a little disingenuous because one extra key stroke is hardly "cumbersome". Especially when you advertise your tool as having VIM bindings and then criticise VIM for the same thing. I have no issues with you promoting your tool but lets be pragmatic about our comparisons here.
You also overlooked the fact that VIM will open any documents from within in. Which would save you a lot more key strokes than tere due to not having to `$EDITOR $file` after the whole (tere|vim) {navigate} process.
As for automatically changing directory. Lets be clear, `tere` doesn't either. You need to configure your shell to do that. Granted you provide the code to set that up but there's nothing stopping someone from writing a similar script for VIM (there's a VimLeave event so you could do something like
and the path would be stored in so it's certainly doable to replicate the same behaviour in VIM. In fact I might even knock up a working script if anything wants it?I'm honestly not saying any of this to be negative about your project here though. It's a nice little tool and I'm sure some people will find it very useful. It's just a common problem so you'll probably find a lot of of people have already solved this with other tools. But there's absolutely nothing wrong with having another tool out there :)
To me, there really is a significant difference in friction when navigating in vim vs tere. Maybe it's because I need to use shift to type '/' on my keyboard layout. But I also have to press enter twice to cd after searching.
The point about opening the files within vim is valid, and I have been considering adding the option to call xdg-open on highlighted files, like many such tools do. I haven't decided yet if that's within the scope of tere.
> It's just a common problem so you'll probably find a lot of people have already solved this with other tools
I agree, and indeed there are a lot of existing alternatives as mentioned in the README. The main motivation for me was to make something that works just the way I want, and secondarily, to write something fun in Rust.
Those two reasons are all the reasons needed for any personal project. I've created so many tools based around those two reasons alone :D
I haven't seen it mentioned yet, but Ranger is a great alternative tool, it can even be integrated into vim
[0]: https://github.com/ranger/ranger
https://github.com/gokcehan/lf