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

171–180 of 206 posts

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

#171

Post by jonnycomputer »

nibbleshifter wrote: post #131
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.

Standalone Python apps as binaries tend to be poorly performant, and huge (due to shipping an interpreter, stdlib, deps, etc) in my experience. Assuming you get it working at all.

I'd prefer an informative rebuttal if people disagree with nibbleshifter, because I want to learn.

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

#172

Post by avgcorrection »

hu3 wrote: post #141
fbanon wrote: post #55

Earlier quoted context omitted.

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

Snottily states that the Rust community loves having too many dependencies and that the cutesy names are stroke-inducing. And you think the replies to that are aggressive?

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

#173

Post by saagarjha »

nibbleshifter wrote: post #155
saagarjha wrote: post #144

Earlier quoted context omitted.

Atrocious but exceptionally battle-tested?

It was the best option a long while ago, and basically resulted in a kind of vendor lock in of sorts. Musl is far superior as a libc, but most Linux software is written for glibc and has quirks that make porting hard.

> Musl is far superior as a libc

Nope. It’s better at some things but with so many caveats that this is just dumb to claim.

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

#174

Post by jhgb »

omni wrote: post #163
jhgb wrote: post #97

Earlier quoted context omitted.

You're saying it's "a common term", but I'd literally never heard it before a Rust library with this exact name appeared. Isn't this by any chance circular reasoning? That it became "a common term" because of this library? In that case you couldn't justify the name of the library by saying that it was "a common term" at that time.

I can assure you this Rust library did not invent the term https://trends.google.com/trends/explore?date=all&geo=US&q=s...

Sadly all I'm constantly getting is "429. That’s an error."

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

#175

Post by eikenberry »

bradwood wrote: post #162
eikenberry wrote: post #159

Earlier quoted context omitted.

To be fair most of those newbies are probably writing scripts that use relative directories so they require them being run in the same directory. Newbies tend to reinforce bad habits like that which makes it harder to break out of those ruts.

(cd ./some/path; ./script.sh)

IMO it's easier just to write your scripts so they don't rely on the directory context for running correctly. Usually it's just a matter of taking your relative path using script and sticking something like this at the top and you're good.

    cd "$(dirname $0)"

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

#176

Post by fouric »

Heh, I implemented almost exactly this same thing several years ago in Python[1], with the main difference just being the amount of polish and feature set. (I was, and continue to be, a very distractible person)

Good to see the idea getting more traction!

[1] https://github.com/fouric/lightning-cd

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

#177

Post by fouric »

chrismorgan wrote: post #29

I strongly dislike the idea of automatically jumping into a folder when there’s only one match: it feels like a feature optimised for very slow typers that actively penalises fast typers, because it makes things generally unpredictable: will one character be enough to navigate, or two, or three? It depends on the siblings, and if you type more characters than are required, you will be penalised by ending up somewhere…

I have the "automatically jump to a folder" setting turned on in my editor's file browser (Emacs with Helm), and it works much better than you're predicting - I rarely end up more folders down than I am shooting for, I don't need to invest much mental energy into prediction, and if I make a mistake, navigating up again is a single chord.

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).

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

#180

Post by nicoburns »

jhgb wrote: post #78
mgunyho wrote: post #18

Earlier quoted context omitted.

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.

Rust is also unlikely to break because of dependency version changes caused by the thirty-seventh party. Despite similarly large dependency trees, the Rust ecosystem takes backwards compatibility much more seriously than e.g. the JavaScript ecosystem.
Post reply on HN