Live data from Hacker News

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

github.com

11–20 of 206 posts

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

#11
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.

`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]
  │       │   └── regex v1.5.4
  │       │       ├── aho-corasick v0.7.18
  │       │       │   └── memchr v2.4.1
  │       │       ├── memchr v2.4.1
  │       │       └── regex-syntax v0.6.25
  │       └── unicode-width v0.1.9
  ├── crossterm v0.24.0
  │   ├── bitflags v1.3.2
  │   ├── libc v0.2.126
  │   ├── mio v0.8.4
  │   │   ├── libc v0.2.126
  │   │   └── log v0.4.14
  │   │       └── cfg-if v1.0.0
  │   ├── parking_lot v0.12.1
  │   │   ├── lock_api v0.4.7
  │   │   │   └── scopeguard v1.1.0
  │   │   │   [build-dependencies]
  │   │   │   └── autocfg v1.1.0
  │   │   └── parking_lot_core v0.9.3
  │   │       ├── cfg-if v1.0.0
  │   │       ├── libc v0.2.126
  │   │       └── smallvec v1.8.0
  │   ├── signal-hook v0.3.13
  │   │   ├── libc v0.2.126
  │   │   └── signal-hook-registry v1.4.0
  │   │       └── libc v0.2.126
  │   └── signal-hook-mio v0.2.3
  │       ├── libc v0.2.126
  │       ├── mio v0.8.4 (*)
  │       └── signal-hook v0.3.13 (*)
  ├── dirs v4.0.0
  │   └── dirs-sys v0.3.6
  │       └── libc v0.2.126
  ├── regex v1.5.4 (*)
  ├── serde v1.0.134
  ├── serde_json v1.0.75
  │   ├── itoa v1.0.1
  │   ├── ryu v1.0.9
  │   └── serde v1.0.134
  ├── textwrap v0.14.2 (*)
  └── unicode-segmentation v1.8.0
I can easily look at each one of these and understand why it’s there, save only a few: most of crossterm’s recursive dependencies, which are fairly involved but the immediate dependencies at least are clearly explained in its README (and you could probably remove one or two of them at minor performance or similar costs); mio’s use of log, which I believe should be optional and I would say not enabled by default, but I’d rather use it with log than miss out on it, where it’s useful; uses of autocfg, which are build-time implementation detail for taking advantage of rustc features where available and readily understood on analysis; and I was going to say cfg-if, which I have a minor personal vendetta against due to extensive unnecessary use, but after looking at parking_lot_core’s src/thread_parker/mod.rs I will begrudgingly admit this is one of the rare cases where it is fairly well-justified. All up, none of the dependencies are in any way unreasonable.

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.

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

#14
post #8

I'm going to be a dick here, because someone will say it anyways, but how is this different from VIM's directory browser? Essentially the same UI. I do think your program does add some features not found in VIM.

It's true that vim probably contains all of the functionality of tere, but IME browsing with vim is still a bit more cumbersome (and I'm not sure if you can configure it to print the cwd on exit, though probably you can). The extra '/' keystroke in each subdirectory for type to search, and the auto-cd really does make tere feel smoother.

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

#15

> "Tere" means "hello" in Estonian. It also feels nice to type. On qwerty I think that's the case :)

It feels bad to type on qwerty. Alternating hands feels nicer to type. That's part of why ls is so hard to remove from peoples' muscle memory.

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

#18
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) unicode handling, and I think adding extra features (proper arg parsing, json for history file etc) would be way more painful.

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

#20
This feels a lot like Vim's built in file explorer (netrw).

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

Post reply on HN