Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: tere – A Faster Alternative to cd+ls

github.com

Post reply on HN
Print view View original

141–150 of 206 posts

Re: Show HN: tere – A Faster Alternative to cd+ls

#141

Post by hu3 »

fbanon wrote: post #55
enriquto wrote: post #6

curl https://raw.githubusercontent.com/mgunyho/tere/master/Cargo.lock | grep source | wc -l 51 How come that such a simple tool has more than half a century of dependencies? This is terrifying.

Well, that's Rust for you. They somehow think that having a boatload of dependencies with nondescript names (smawk, parking_lot_core, serde, clap - I feel like I'm having a stroke) is a feature. I'm not even joking.

The aggressive replies on this thread. holy s**t.

That's what I mean when I say Rust community is toxic here https://news.ycombinator.com/item?id=32105449

Re: Show HN: tere – A Faster Alternative to cd+ls

#142

Post by mgunyho »

chrismorgan wrote: post #139
mgunyho wrote: post #108

Earlier quoted context omitted.

Indeed, Python would be a good language to implement this in terms of ease of development, but it's very difficult to distribute a standalone binary (which I wanted to do). The built-in curses support of Python is also not cross-platform I think.

It’s a funny thing I’ve noticed about scripting languages: they’re generally easier to get going with yourself, but they’re horrible for distribution/deployment, and if you have to integrate code written in other languages (even C libraries with Python bindings, or similar—things like wxWidgets or GTK), that rapidly escalates to a nightmare . Meanwhile, ahead-of-time compiled languages like Rust and Go are simply a b…

That's true, although I think in the case of Go, it is a central design decision to make single-binaries easy so it's more of an exception to the rule.

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.

Re: Show HN: tere – A Faster Alternative to cd+ls

#143

Post by nickjj »

lloeki wrote: post #118
nickjj wrote: post #68

Earlier quoted context omitted.

> could I achieve that with fzf? I've been sporting this alias for a while now: alias pf="fzf --preview='less {}' --bind shift-up:preview-page-up,shift-down:preview-page-down" 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.

N'other silly one: git log --oneline --decorate --color | fzf --ansi --preview 'git show $(echo {} | cut -d" " -f1)' The possibilities, they are _endless_ !!11!1!

Indeed!

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

Re: Show HN: tere – A Faster Alternative to cd+ls

#144

Post by saagarjha »

nibbleshifter wrote: post #128
nonameiguess wrote: post #93

Earlier quoted context omitted.

This isn't true, though. If this had been an older GNU utility, the dependencies likely would have been libterm and libc. Not because it would have been less complex, but because of the ecosystem choice in C applications to have larger, fully-featured libraries versus the micro-libraries Rust seems to have inherited from JavaScript conventions. Whether this is better or worse seems to be a matter of contention for a…

> If this had been an older GNU utility, the dependencies likely would have been libterm and libc. Yes, but then you are stuck with glibc + kitchen sink and GNU code quality, which is atrocious.

Atrocious but exceptionally battle-tested?

Re: Show HN: tere – A Faster Alternative to cd+ls

#145

Post by infinityio »

chrismorgan wrote: post #126
mxben wrote: post #122

Earlier quoted context omitted.

> As soon as something enters the standard library its API is basically set in stone Is that really all that different from Python?

No, that’s the point: if you put this stuff in the standard library, it gets frozen forever, and that’s why Rust doesn’t .

To quote the python developers guide:

> 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

Re: Show HN: tere – A Faster Alternative to cd+ls

#146

Post by saagarjha »

mynameisvlad wrote: post #105
bowsamic wrote: post #66

Earlier quoted context omitted.

I don't mind the number of dependencies, but I agree that the cutesy naming is ridiculous and obfuscating

You're free to create your own project with your own name and have it compete on the free market for dominance. I don't get this criticism at all. Sure, it could be simpler, but it's A. Not your project, so who are you to say how to name it and B. Rust developers clearly understand what they're used for considering they're popular enough to be brought up here. And unless you're actively developing in Rust, why would…

Don't Rust crates go in a global namespace? In that case using up common or short names is definitely something I get to care about.

Re: Show HN: tere – A Faster Alternative to cd+ls

#147

Post by divbzero »

mgunyho wrote: post #23
freedomben wrote: post #19

I'm blown away at the quality of the readme :-) 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?

Funny, to me showing the keystrokes felt like a cliche in "modern"/flashy CLI app readmes :) I guess it's more often used in youtube videos. 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

Echoing neighbor comments that the README is very well done. I specifically searched through this thread to learn how you displayed those keystrokes in the demo.

Re: Show HN: tere – A Faster Alternative to cd+ls

#148

Post by ghostly_s »

Do people actually still use cd + ls? At least in bash, you get a similar experience just typing a cd command and tab-completing the path elements - bash shows a listing of matches when your command is ambiguous, no `ls` required.I'll still check it out as I can see fuzzy-search being more useful but muscle memory is hard to change.

Re: Show HN: tere – A Faster Alternative to cd+ls

#149

Post by divbzero »

asib wrote: post #36

Is cd+ls a common pattern for people? I tend to just use double tab to browse folders, combined with a file separator-aware "delete word" keybinding when I want to go back up one level.

I use cd+ls all the time even though double tab or fzf [1] work better in theory.

[1]: https://github.com/junegunn/fzf#key-bindings-for-command-lin...

Re: Show HN: tere – A Faster Alternative to cd+ls

#150

Post by pessimizer »

scrollaway wrote: post #34
enriquto wrote: post #6

curl https://raw.githubusercontent.com/mgunyho/tere/master/Cargo.lock | grep source | wc -l 51 How come that such a simple tool has more than half a century of dependencies? This is terrifying.

The "too many dependencies" meme is far too often an example of Chesterton's Fence. 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".

I don't think you can cite Chesterton's Fence for something that is 5 minutes old and lightly used. The Chesterton's Fence meme is far too often an excuse for baselessly dismissing criticism.
Post reply on HN