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

71–80 of 206 posts

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

#71

Post by jonnycomputer »

chrismorgan wrote: post #42
mgunyho wrote: post #38

Earlier quoted context omitted.

I'm a fast typer, and I understand where you're coming from! But note how there's a small (200ms by default but can be configured) delay when the auto-cd happens. This is actually pretty important, because otherwise it's impossible to see where you cd'd to. Importantly, during this delay, the keystrokes are eaten (so they are not fed down to the next level), and from my experience this is enough to basically never ac…

OK, delay sounds good.

I think you were highlighting an important potential usability issue; the delay might be ok, but I still prefer a keystroke, such as enter, to confirm selection.

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

#73

Post by andai »

tipsytoad wrote: post #61

Looks great! I was thinking of a rusty pet project for the same thing :) 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

See also lf, inspired by ranger.

https://github.com/gokcehan/lf

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

#74

Post by kybernetyk »

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.

Just wait till the deps go away or change in some significant way.

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

#76

Post by omni »

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.

Serde is a common term meaning "serialization/deserialization," seems pretty descript to me.

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

#78

Post by jhgb »

mgunyho wrote: post #18
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.

I tried to avoid bloat as much as possible, and I would argue that the non-transitive deps are pretty essential. I'l look into tweaking some features as suggested in sibling to trim it further down. 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) unico…

I wonder, have you considered D? Seems almost ideal to me for this kind of small tooling, and it's unlikely to break because of dependency version changes caused by the thirty-seventh party.

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

#80

Post by chrismorgan »

Aeolun wrote: post #69
avgcorrection wrote: post #53

Earlier quoted context omitted.

> that actively penalises fast typers, I think the word you are looking for is “indirectly”.

That feels kinda direct though?

Eh, I get what avgcorrection was going for—unintentionally, incidentally. Depending on the angle you look at it, it could count as both direct and indirect. I’ll stand by “actively”.
Post reply on HN