Live data from Hacker News

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

github.com

31–40 of 206 posts

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

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

Not everyone uses Vim.

Also netrw is a bit of a mess; I once found a bug and thought "I'll write a patch". After five minutes of browsing through the code ([insert Eddie Murphy meme]): "yeah, never mind".

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

#32
post #13

> "Tere" means "hello" in Estonian. It also feels nice to type. I really thought it was initially a typo on "tree" (the tool's purpose is to navigate the folder tree) that the author decided to keep.

I think the origin might be ”[ter]minal file [e]xplorer”, though the author might correct me here.

”Tere” is also, perhaps unsurprisingly, used in Finnish.

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

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

Why don’t you suggest dependencies that could be removed? Oh right. That would require effort.

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

#34
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".

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

#35
post #17

Looks like builtin in zsh autoload -Uz compinit compinit zstyle ':completion:*' menu select Then ‘cd ’

Tab completion with these settings takes some extra keystrokes: if there's only one match, you have to press tab twice to see what's in the subfolder. If you have several matches, you have to press tab, then enter to select the one you want, and then tab again to show the subfolder contents. And going up (especially several) folders is also quite a bit of typing. It might sound like splitting hairs to shave off less than five keystrokes, but it really does make a difference in how smooth the browsing feels.

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

#37
Congrats for getting this out!

> I also wanted an excuse to learn

This is the best reason ever, and not just for you: seeing your GIF I thought "could I achieve that with fzf?". Turns out, yes I can:

    function fcd() {
      local dir;
    
      while true; do
        # exit with ^D
        dir="$(ls -a1p | grep '/$' | grep -v '^./$' | fzf --height 40% --reverse --no-multi --preview 'pwd' --preview-window=up,1,border-none --no-info)"
        if [[ -z "${dir}" ]]; then
          break
        else
          cd "${dir}"
        fi
      done
    }
Certainly not the best code (and definitely not a jab at your implementation!) but, hey, it was purely for the heck of it.

Lately I've been trying to find the joy in programming again, these kind of fun little challenges help a lot, so thanks for sharing, enthusiasm and creativity is contaminating :)

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

#38

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'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 accidentally cd in the lower level.

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

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

#39
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 don't know about other people, but I use the combo almost all the time when I need to `cd`.

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

#40
post #37

Congrats for getting this out! > I also wanted an excuse to learn This is the best reason ever, and not just for you: seeing your GIF I thought "could I achieve that with fzf?". Turns out, yes I can: function fcd() { local dir; while true; do # exit with ^D dir="$(ls -a1p | grep '/$' | grep -v '^./$' | fzf --height 40% --reverse --no-multi --preview 'pwd' --preview-window=up,1,border-none --no-info)" if [[ -z "${dir}…

Thanks for the kind words! :)

While digging up alternatives (of course after I had already written most of the functionality), I briefly tried out fzf. I think at that time I couldn't find an example snippet like yours to do the cding, so I didn't look into it much more. With some basic settings, it was also not easy (or even possible?) to go up in the folder tree, but I see that your example handles that.

If you're unfamiliar with a big folder tree, fzf (or another very similar tool that is designed for this purpose, broot) can be more efficient. But it might take a while for it to scan all subfolders.

Post reply on HN