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

101–110 of 206 posts

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

#101

Post by Cthulhu_ »

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've got ZSH or a ZSH plugin that shows me a list of possible files in a folder I'm cd-ing into, without going into a different 'terminal mode'. Works for things like vim as well.

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

#102

Post by sayanarijit »

jonnycomputer wrote: post #99
chrismorgan wrote: post #11

Earlier quoted context omitted.

`cargo tree` output: tere v1.0.0 ├── clap v3.0.10 │ ├── bitflags v1.3.2 │ ├── indexmap v1.8.0 │ │ └── hashbrown v0.11.2 │ │ [build-dependencies] │ │ └── autocfg v1.1.0 │ ├── os_str_bytes v6.0.0 │ │ └── memchr v2.4.1 │ ├── strsim v0.10.0 │ ├── terminal_size v0.1.17 │ │ └── libc v0.2.126 │ └── textwrap v0.14.2 │ ├── smawk v0.3.1 │ ├── terminal_size v0.1.17 (*) │ ├── unicode-linebreak v0.1.2 │ │ [build-dependencies] │ │…

I don't know much about Rust, but I have a hard time believing python's standard library wouldn't have all the required functionality covered (whether performance would be adequate is different question). I for one, really really like python for its comprehensive standard library.

As long as there's no need to ship standalone binaries without shared libraries.

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

#103

Post by mynameisvlad »

jonnycomputer wrote: post #71
chrismorgan wrote: post #42

Earlier quoted context omitted.

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.

> The auto-cd can also be turned off with a CLI option.

Which was seemingly addressed as well, no?

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

#104

Post by mynameisvlad »

reaperducer wrote: post #86
chrismorgan wrote: post #11

Earlier quoted context omitted.

`cargo tree` output: tere v1.0.0 ├── clap v3.0.10 │ ├── bitflags v1.3.2 │ ├── indexmap v1.8.0 │ │ └── hashbrown v0.11.2 │ │ [build-dependencies] │ │ └── autocfg v1.1.0 │ ├── os_str_bytes v6.0.0 │ │ └── memchr v2.4.1 │ ├── strsim v0.10.0 │ ├── terminal_size v0.1.17 │ │ └── libc v0.2.126 │ └── textwrap v0.14.2 │ ├── smawk v0.3.1 │ ├── terminal_size v0.1.17 (*) │ ├── unicode-linebreak v0.1.2 │ │ [build-dependencies] │ │…

hashbrown, smawk, corasick, parking_lot, itoa, ryu Writing in Rust looks like casting spells in an Infocom game. Gnusto rezrov!

Really? itoa is one of your "magic incantations"?

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

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

#105

Post by mynameisvlad »

bowsamic wrote: post #66
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.

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 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?

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

#106

Post by mgunyho »

mynameisvlad wrote: post #104
reaperducer wrote: post #86

Earlier quoted context omitted.

hashbrown, smawk, corasick, parking_lot, itoa, ryu Writing in Rust looks like casting spells in an Infocom game. Gnusto rezrov!

Really? itoa is one of your "magic incantations"? 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

Also, aho-corasick comes from the name of this algorithm that is named after its inventors https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm

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

#107

Post by enriquto »

mynameisvlad wrote: post #104
reaperducer wrote: post #86

Earlier quoted context omitted.

hashbrown, smawk, corasick, parking_lot, itoa, ryu Writing in Rust looks like casting spells in an Infocom game. Gnusto rezrov!

Really? itoa is one of your "magic incantations"? 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

What is the point of this function? In rust, there's no equivalent to sprintf?

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

#108

Post by mgunyho »

sayanarijit wrote: post #102
jonnycomputer wrote: post #99

Earlier quoted context omitted.

I don't know much about Rust, but I have a hard time believing python's standard library wouldn't have all the required functionality covered (whether performance would be adequate is different question). I for one, really really like python for its comprehensive standard library.

As long as there's no need to ship standalone binaries without shared libraries.

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.

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

#109

Post by mynameisvlad »

enriquto wrote: post #107
mynameisvlad wrote: post #104

Earlier quoted context omitted.

Really? itoa is one of your "magic incantations"? 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

What is the point of this function? In rust, there's no equivalent to sprintf?

https://doc.rust-lang.org/std/fmt/

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.

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

#110

Post by wongarsu »

jonnycomputer wrote: post #99
chrismorgan wrote: post #11

Earlier quoted context omitted.

`cargo tree` output: tere v1.0.0 ├── clap v3.0.10 │ ├── bitflags v1.3.2 │ ├── indexmap v1.8.0 │ │ └── hashbrown v0.11.2 │ │ [build-dependencies] │ │ └── autocfg v1.1.0 │ ├── os_str_bytes v6.0.0 │ │ └── memchr v2.4.1 │ ├── strsim v0.10.0 │ ├── terminal_size v0.1.17 │ │ └── libc v0.2.126 │ └── textwrap v0.14.2 │ ├── smawk v0.3.1 │ ├── terminal_size v0.1.17 (*) │ ├── unicode-linebreak v0.1.2 │ │ [build-dependencies] │ │…

I don't know much about Rust, but I have a hard time believing python's standard library wouldn't have all the required functionality covered (whether performance would be adequate is different question). I for one, really really like python for its comprehensive standard library.

Yes, Rust has a very different philosophy to the standard library. As soon as something enters the standard library its API is basically set in stone, since there's no versioning for the standard lib. As a consequence, Rust choses to keep a lot of "must-have" functionality in crates, where it can evolve and compete. (rather than just adding more and more HTTP clients to the standard lib like Python did :) )
Post reply on HN