[HN Gopher] Show HN: tere - A Faster Alternative to cd+ls
___________________________________________________________________
Show HN: tere - A Faster Alternative to cd+ls
Hi HN! I wrote a small program to browse folders in the terminal.
The main inspiration was type-ahead search in GUI file managers.
There exist several programs that are similar (see the listing in
the README), but none of them do it quite the way I like, and often
they have a very complex UI and a ton of features. I tried to make
something that is obvious how to use and gets out of your way. (I
also wanted an excuse to learn Rust.) Let me know what you think!
Author : mgunyho
Score : 318 points
Date : 2022-07-15 08:45 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sillycube wrote:
| syntaxfree wrote:
| I alias cd to pushd but half the time I forget to popd. It would
| be cool if there was a tool like this that would produce a menu
| from my pushd queue.
| asib wrote:
| 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.
| divbzero wrote:
| I use cd+ls all the time even though double tab or fzf [1] work
| better in theory.
|
| [1]: https://github.com/junegunn/fzf#key-bindings-for-command-
| lin...
| p4bl0 wrote:
| Same here, I use ls when I'm where I want to be, but for
| navigating the filesystem to there, I use cd and TAB TAB
| autocompletion (which is smart enough to only suggest
| directories).
| memorable wrote:
| I don't know about other people, but I use the combo almost all
| the time when I need to `cd`.
| Cthulhu_ wrote:
| 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.
| lloeki wrote:
| 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 :)
| [deleted]
| msravi wrote:
| This is great, thank you! Just a couple of minor changes to
| handle softlinks to folders... function fcd() {
| local dir; while true; do # exit with
| ^D dir="$(ls -a1F | grep '[/@]$' | grep -v '^./$' |
| sed 's/@$//' | fzf --height 40% --reverse --no-multi --preview
| 'pwd' --preview-window=up,1,border-none --no-info)"
| if [[ -z "${dir}" ]]; then break elif [[
| -d "${dir}" ]]; then cd "${dir}" fi
| done }
| mgunyho wrote:
| 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.
| capdeck wrote:
| What about `skim` - integrating it as a library? fzf is nice,
| but it is external - you have to pre-install and configure
| it.
| lloeki wrote:
| > fzf (or another very similar tool that is designed for this
| purpose, broot) can be more efficient
|
| Well, fzf is only a selection tool, it's more about the tool
| that feeds fzf data ;) That's why I used a dumb _ls_ in my
| example. Maybe a difference with yours is that it _does_
| perform cd on each loop, and there 's no way to bail out and
| _not_ cd.
|
| > it might take a while for it to scan all subfolders.
|
| Haha yeah, for recursive cases I was using ripgrep as fzf
| default command: rg --files --no-ignore
| --hidden --follow --glob "!{.git,node_modules}/*" | fzf
|
| And now I just discovered fd[0]: fd --no-
| ignore --hidden --follow --strip-cwd-prefix | fzf
|
| (...at least essentially, my setup is a bit more tunable and
| complex, I have a few of these with varying flags depending
| on the situation and goal)
|
| [0]: https://github.com/sharkdp/fd#using-fd-with-fzf
| [deleted]
| nickjj wrote:
| > could I achieve that with fzf?
|
| I've been sporting this alias for a while now:
| alias pf="fzf --preview='less {}' --bind shift-up:preview-page-
| up,shift-down:preview-page-down"
|
| You can run `pf` (preview file) in a directory and it opens a
| split window with fzf where you can preview text files with
| less and optionally filter down which files are matched with
| fzf.
|
| fzf is great.
| lloeki wrote:
| N'other silly one: git log --oneline
| --decorate --color | fzf --ansi --preview 'git show $(echo {}
| | cut -d" " -f1)'
|
| The possibilities, they are _endless_ !!11!1!
| nickjj wrote:
| Indeed!
|
| If you're using the fzf.vim plugin[0] you can run
| `:Commits` to do something similar to your command too. It
| adds a bit more detail such as when the commit was made in
| relative format and color codes the git diff.
|
| [0]: https://github.com/junegunn/fzf.vim
| make3 wrote:
| you should put this on github
| gregwebs wrote:
| Nice! exa (an attempt at a better ls) has a -D option, so then
| it is `exa -a1D` without the grep. I created a second version
| that also adds -R for searching the recursive directory tree
| with `exa -a1DR | grep : | cut -d ':' -f 1`
| obituary_latte wrote:
| FYI: I think you meant "contagious" rather than
| "contaminating". The latter means to make something impure
| whereas the former means more to spread something. :)
| bradwood wrote:
| Contagion?
| lloeki wrote:
| Indeed!
| carapace wrote:
| (I'm beginning to think auto-correct should be called auto-
| malaprop.
|
| The best one I've seen recently was a fellow enthusing about
| the descendant of Plan 9 who wrote, "I'll always singe the
| praises of Inferno!".)
| bradwood wrote:
| One of my pet peeves is CLI newbies who always have the need to
| cd into some directory before running a command. I learnt pretty
| early on that this was stupid.
|
| Just run your command from the repo root or $HOME.
| eikenberry wrote:
| 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.
| bradwood wrote:
| (cd ./some/path; ./script.sh)
| eikenberry wrote:
| 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)"
| [deleted]
| post-factum wrote:
| Now in AUR too [1].
|
| [1] https://aur.archlinux.org/packages/tere
| mixmastamyk wrote:
| This is quite neat so I feel slightly embarrassed to share my
| low-tech solution. Just run a "dir" after each "cd" (which is my
| alias for "ls -l --si ...").
|
| It's written for fish, but could be ported to bash easily:
| # cat ~/.config/fish/functions/cd.fish function cd
| builtin cd $argv; if test $status -gt 0 # there was
| an error, stop return end
| # auto print dir info if test "$argv" != "" # not
| home though dir end end
|
| There's probably a way to optimize out the "test " call as well,
| but I haven't got around to it.
| ghostly_s wrote:
| Do people actually still use cd + ls? At least in bash, you get a
| similar experience just typing a cd command and tab-completing
| the path elements - bash shows a listing of matches when your
| command is ambiguous, no `ls` required.I'll still check it out as
| I can see fuzzy-search being more useful but muscle memory is
| hard to change.
| tux2bsd wrote:
| not entirely. e.g.
|
| cd tab tab directories listed
|
| cat tab tab files listed
|
| (this^^ is on Debian, it can probably be changed but I've not
| looked into it)
|
| it's pretty annoying when I'm halfway through and want to use
| tab tab as a periscope to see all file+dirs
| sileht wrote:
| Looks like builtin in zsh
|
| autoload -Uz compinit compinit
|
| zstyle ':completion:*' menu select
|
| Then 'cd <tab>'
| mgunyho wrote:
| 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.
| realyashnag wrote:
| The reason devs still use `cd+ls` is because they're ubiquitous.
| But always great to learn new stuff like this (:
| rebanevapustus wrote:
| A Small bit of trivia: tere means hi in Estonian.
| mgunyho wrote:
| That's mentioned in the readme! :) I'm pretty happy with the
| name choice, it's short, doesn't seem to clash with other CLI
| tools, it can be interpreted as "terminal explorer", and has a
| kind of cute meaning as you say.
| notpushkin wrote:
| Tere from Tallinn here! :-)
| ducktective wrote:
| Nice project! Kudos!
|
| BTW, checkout `nnn` search-as-you-type and cd-on-quit features. I
| think its similar in scope to this project.
|
| https://github.com/jarun/nnn
|
| https://github.com/jarun/nnn/wiki/Basic-use-cases#configure-...
| hnlmorg wrote:
| Appreciate this is a hobby project to learn Rust in, but for
| those who want similar functionality without installing
| additional dependencies, you can already do this in `vim` by
| selecting a directory to open instead of a file.
|
| For example vim ~ vim /etc
|
| It has more or less the same UI as the one in this Show HN but
| with the added feature of opening any files you select.
| mgunyho wrote:
| As mentioned in another comment, vim doesn't provide exactly
| the same experience: navigation is more cumbersome because you
| need extra keystrokes for type-to-search and to cd a folder. It
| also requires some extra tinkering for vim to print out the cwd
| when you exit.
| hnlmorg wrote:
| Clearly it's not going to be functionally identical, which is
| why I said it might interest people who are after something
| similar "without installing additional dependencies".
|
| That said, I do think your reply here is a little
| disingenuous because one extra key stroke is hardly
| "cumbersome". Especially when you advertise your tool as
| having VIM bindings and then criticise VIM for the same
| thing. I have no issues with you promoting your tool but lets
| be pragmatic about our comparisons here.
|
| You also overlooked the fact that VIM will open any documents
| from within in. Which would save you a lot more key strokes
| than tere due to not having to `$EDITOR $file` after the
| whole (tere|vim) {navigate} process.
|
| As for automatically changing directory. Lets be clear,
| `tere` doesn't either. You need to configure your shell to do
| that. Granted you provide the code to set that up but there's
| nothing stopping someone from writing a similar script for
| VIM (there's a VimLeave event so you could do something like
| :autocmd VimLeave *
|
| and the path would be stored in
| expand('%:p:h')
|
| so it's certainly doable to replicate the same behaviour in
| VIM. In fact I might even knock up a working script if
| anything wants it?
|
| I'm honestly not saying any of this to be negative about your
| project here though. It's a nice little tool and I'm sure
| some people will find it very useful. It's just a common
| problem so you'll probably find a lot of of people have
| already solved this with other tools. But there's absolutely
| nothing wrong with having another tool out there :)
| mgunyho wrote:
| > one extra keystroke is hardly cumbersome
|
| To me, there really is a significant difference in friction
| when navigating in vim vs tere. Maybe it's because I need
| to use shift to type '/' on my keyboard layout. But I also
| have to press enter twice to cd after searching.
|
| The point about opening the files within vim is valid, and
| I have been considering adding the option to call xdg-open
| on highlighted files, like many such tools do. I haven't
| decided yet if that's within the scope of tere.
|
| > It's just a common problem so you'll probably find a lot
| of people have already solved this with other tools
|
| I agree, and indeed there are a lot of existing
| alternatives as mentioned in the README. The main
| motivation for me was to make something that works just the
| way I want, and secondarily, to write something fun in
| Rust.
| hnlmorg wrote:
| > _The main motivation for me was to make something that
| works just the way I want, and secondarily, to write
| something fun_
|
| Those two reasons are all the reasons needed for any
| personal project. I've created so many tools based around
| those two reasons alone :D
| freedomben wrote:
| I'm blown away at the quality of the readme :-)
|
| In the demo, how did you get the key press indicator to show? I
| haven't seen that before, but it's a wonderful addition. And may
| I ask what you used to record it?
| tommiegannert wrote:
| I was thinking the same. Building something without sharing is
| one thing. Dumping code on GitHub is second level. Third is
| building a good README. Fourth is building a good README and
| announcing it to the right audience.
|
| Very well executed.
|
| I'm not sure there's a level between fifth and "being
| obnoxiously pushy," but if there's such a thing, I'd be
| interested to know. :)
| mgunyho wrote:
| Funny, to me showing the keystrokes felt like a cliche in
| "modern"/flashy CLI app readmes :) I guess it's more often used
| in youtube videos.
|
| I used screenkey to display the keystrokes and Peek to record
| the gif. I actually wrote some instructions for myself so I
| remember how I did it if I want to update the gif:
| https://github.com/mgunyho/tere/blob/master/demo/README.md
| divbzero wrote:
| Echoing neighbor comments that the README is very well done.
| I specifically searched through this thread to learn how you
| displayed those keystrokes in the demo.
| codecurve wrote:
| 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
| tipsytoad wrote:
| 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
| andai wrote:
| See also lf, inspired by ranger.
|
| https://github.com/gokcehan/lf
| tsujp wrote:
| Similar but in pure Bash: https://github.com/dylanaraps/fff
| kleer001 wrote:
| Looks like fun to use and it was fun to create.
|
| I don't see a use case for myself. I use cd with TAB autocomplete
| and I'm set. I'm old enough and lazy enough.
| iso1631 wrote:
| I hit ~ expecting to go to my home directory, which was a bit odd
|
| Once I select a directory I want to dump myself back out into a
| command line in that directory, I couldn't see the key for that?
| Or am I misunderstanding the purpose?
| mgunyho wrote:
| To end up in the directory where you are, you just have to exit
| using esc or alt-q, assuming you have set up your shell config.
|
| I'll add ~ as a shortcut for the home directory, thanks for the
| good idea! (It conflicts with type-to-search for folders
| starting with '~', but I think that's much less common than
| cding to home.)
| fouric wrote:
| 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
| protonbob wrote:
| I really like the animated gif. It really is useful to show how
| the program works.
| seligman99 wrote:
| Similar idea for Windows:
|
| https://github.com/seligman/ccd
|
| ccd is more concerned with an edge-first search, and since it's
| Windows, actually changing the directory involves a thread
| insertion in the cmd process to do the work ... which somehow
| works.
| the_alchemist wrote:
| > "Tere" means "hello" in Estonian. It also feels nice to type.
|
| On qwerty I think that's the case :)
| fnord123 wrote:
| 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.
| [deleted]
| mgunyho wrote:
| Note that setting up tere requires defining an alias in your
| shell config anyway, so you can choose any name you want with
| basically zero extra effort! Except for coming up with an
| abbreviation you remember, of course. But I agree, it is
| faster to type with alternating hands.
| mgunyho wrote:
| True, it's not a very smooth experience on non-qwerty
| keyboards, and the keyboard shortcuts can't be customized yet.
| But it's high on the todo list!
| j1elo wrote:
| One thing I'd like is a cd command incantation that when given a
| file path, it just changes to the dir containing such file.
|
| It is such a common need (for me at least) that I'm surprised the
| standard cd doesn't do it already.
|
| I find myself using find or locate, then wanting to change to
| some file's directory, thus needing to manually delete the file's
| name before hitting enter. When you do that enough times you
| start to wish it worked automatically :-)
| mpweiher wrote:
| function cdf { cd `dirname $1` }
|
| From my .zsrhc. This only does the file use case, it doesn't
| work for directories. Probably easy enough to add.
| j1elo wrote:
| Our dot files are always growing with small helpful bits like
| this one :) Thanks for the idea!
| jhgb wrote:
| Well, what I think... It looks cool, but fish already includes
| similar functionality in its directory completion, so no external
| program required. So I suspect this is useful for people using
| bash and such?
| medv wrote:
| I also created a such tool llama:
|
| https://github.com/antonmedv/llama
|
| But with fuzzy searching.
| mgunyho wrote:
| Nice, looks like this is indeed very similar to tere! I guess
| the biggest difference is that the current search is not as
| "sticky", looks like it's cleared automatically after a while,
| which is similar to the behavior of the windows file explorer.
| I added it to the list of similar programs in the README (it's
| in the develop branch for now).
| a3w wrote:
| Nice of the readme to mention broot et al.
| chungus wrote:
| Cool! Also, I really like your demo gif! Super effective and fun
| way to go through all the features.
| enriquto wrote:
| 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.
| res0nat0r wrote:
| Cargo.lock is the wrong place to be looking, there really are
| only 7 direct dependencies,
| https://github.com/mgunyho/tere/blob/master/Cargo.toml#L14-L...
|
| The deps for each of these packages is really out of the
| authors hands, this is really the same for any programming
| language though which need to pull in dependencies of their
| own.
| bscphil wrote:
| That's true, but OP did ask a question "How come...". Your
| answer is that the Rust ecosystem is to blame for encouraging
| micro-dependencies, like Node.js, and not the author. I think
| that's a pretty reasonable take! But it doesn't mean that
| there's not a problem.
| topspin wrote:
| Code reuse was once considered a virtue.
| geodel wrote:
| Agree. That's why I will never re-write function is-
| Thirteen() when a battle-tested reusable package exists
| in NPM exactly for this.
| zaptheimpaler wrote:
| > This is terrifying.
|
| I recommend either CBT or writing your own version with fewer
| dependencies to ease your terror.
| scrollaway wrote:
| 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".
| pessimizer wrote:
| I don't think you can cite Chesterton's Fence for something
| that is 5 minutes old and lightly used. The Chesterton's
| Fence meme is far too often an excuse for baselessly
| dismissing criticism.
| scrollaway wrote:
| This project is 7 months old with almost 800 commits.
|
| The comment I replied to is less than 100 characters long
| plus a command line invocation.
|
| One of these two has spent more time thinking about whether
| some dependencies are needed.
| nonameiguess wrote:
| This isn't true, though. If this had been an older GNU
| utility, the dependencies likely would have been libterm and
| libc. Not because it would have been less complex, but
| because of the ecosystem choice in C applications to have
| larger, fully-featured libraries versus the micro-libraries
| Rust seems to have inherited from JavaScript conventions.
|
| Whether this is better or worse seems to be a matter of
| contention for a lot of people, but it certainly poses a
| challenge for supply-chain auditing. I suspect for Rust to
| truly ever replace C++ in its domain, the ecosystem is going
| to need to come up with something like boost so you can grab
| one library that does all the things nearly any program wants
| (regex, serialization, cli opts, etc) but that don't get
| included in the core language's stdlib.
| nibbleshifter wrote:
| > If this had been an older GNU utility, the dependencies
| likely would have been libterm and libc.
|
| Yes, but then you are stuck with glibc + kitchen sink and
| GNU code quality, which is atrocious.
| saagarjha wrote:
| Atrocious but exceptionally battle-tested?
| nibbleshifter wrote:
| 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.
| saagarjha wrote:
| > 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.
| alerighi wrote:
| Musl is liked since it has a non-copyleft license and
| thus can be used to produce statically-linked executable
| that are distributed with proprietary licenses. Also Musl
| is smaller than GLibc thus more suitable for embedded
| systems.
|
| Anyway, GLibc is just better, both in terms of
| performance (algorithms are more optimized, at the cost
| of a bigger executable size) and in terms of available
| features.
| enriquto wrote:
| > Musl is liked since it has a non-copyleft license
|
| Not only for that. As much as I love copyleft, I'm really
| happy that musl exists so that I can easily test my
| programs locally for portability. Compiling stuff with
| different compilers and libraries exposes at once all
| sorts of weird bugs before you get to publish your codes.
| avgcorrection wrote:
| Doesn't C come out of that weird do-one-thing-and-do-it-
| well culture?
| mgunyho wrote:
| 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.
| jhgb wrote:
| 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.
| mgunyho wrote:
| Not really. The main reason for choosing Rust was to try it
| out, because it's the new cool thing. And I do find it
| really enjoyable. Rust is also trying very hard to keep
| dependency-related breakage to a minimum, and I think the
| Cargo ecosystem is doing a great job at that.
| jhgb wrote:
| Fair enough; "I wanted to try out X" is always a valid
| reason. It's just that compared to C, things like Unicode
| support, argument parsing and JSON support are already
| part of D's standard library so no dependencies should be
| required for those.
| nicoburns wrote:
| 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.
| jhgb wrote:
| Well, I should hope so. Nevertheless every dependency
| removed completely removes even the possibility of such
| breakage.
| nicoburns wrote:
| I mean sure, but it means you have to maintain that
| functionality yourself. Often DIY implementations are not
| as robust as the versions in battle tested libraries with
| lots of eyes. So you can easily end up with more problems
| overall.
| capdeck wrote:
| I disagree with "bloat" comments. First, the binary will only
| have stuff you use. Secondly, the fact that you are not
| writing from scratch code that someone else had more time to
| write and test - this is a huge plus. I'd use your
| implementation any day vs. something that someone could put
| together in C with no dependencies and remarkable pointer
| math equilibristics.
|
| As long as the use of dependencies remains reasonable, the
| number of dependencies does not immediately mean that the
| code is "bloated".
| kybernetyk wrote:
| Just wait till the deps go away or change in some significant
| way.
| sayanarijit wrote:
| Not in rustland.
| steveklabnik wrote:
| They cannot be removed without good reason (like "here's a
| letter from my lawyer" or "this code secretly exfiltrates
| credentials"), and a lock file means that even if they
| change, your usage of them won't until you ask to upgrade
| versions.
| fbanon wrote:
| 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.
| bowsamic wrote:
| I don't mind the number of dependencies, but I agree that the
| cutesy naming is ridiculous and obfuscating
| mynameisvlad wrote:
| 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?
| bowsamic wrote:
| You can say this about literally any criticism ever. I
| hate it and it blows chunks. It is the ultimate
| libertarian way of striking down any discussion: do not
| criticise, even in any small way, because it's a free
| market and you can just make another one, so never EVER
| even THINK of discussing anything.
|
| I'm not saying that there should be some kind of
| totalitarian regime that enforces naming, I'm simply
| saying that yeah it kinda sucks that Rust devs tend
| towards cutesy names over ones that convey functionality.
|
| This just seems like you're getting weirdly offended for
| no reason. Not everything is some kind of attack on
| individual agency. There is absolutely nothing wrong with
| me remarking on the state of Rust naming. The fact that
| you are conflating it to be a "big deal", which I never
| said it was, just seems like bad faith arguing me. This
| is just not something to get so offended over.
| mynameisvlad wrote:
| > I'm simply saying that yeah it kinda sucks that Rust
| devs tend towards cutesy names over ones that convey
| functionality.
|
| Are you using Rust? If not, why does it matter what they
| choose to name their libraries. This is my entire point,
| you're coming in as an outsider criticizing something
| that is _clearly not a problem to Rust devs_.
|
| If _actual_ Rust developers are using them to the point
| where they 're popular enough to gain (unwarranted, imo)
| criticism, then clearly they're working, silly name and
| all.
|
| It's almost as if people care more about what the
| function a package provides rather than its name.
| geodel wrote:
| Why the hell one has to use Rust to comment on library
| name? Is there some license requirement for comments on
| Rust stuff? It's not like that people go on GitHub and
| tell authors that their project names are silly and need
| to be changed.
|
| This is exactly cultish thing about Rust, that unless
| someone is praising Rust, they are free to keep their
| mouth shut.
| bowsamic wrote:
| I'm not an outsider, I have used rust before, though not
| extensively, not that this matters at all. An active rust
| developer has no more permission to criticise something
| about the rust ecosystem than someone new to rust
| mynameisvlad wrote:
| But it does matter. If the people actively using the
| packages aren't complaining, then there isn't really a
| problem.
|
| You've hyperfocused _so_ much on my "criticism of your
| criticism" and the permissibility behind it that you
| chose to ignore the actual criticism I laid down.
|
| I'm not continuing this either way since I've said my
| piece. Maybe step back and actually read my comments
| rather than focusing on me criticizing your critique.
|
| Also, pot calling the kettle black. You spent an entire
| comment being offended over my critique.
| bowsamic wrote:
| You probably shouldn't make such inflammatory comments on
| an account that is directly linked to your professional
| and personal profiles, it really doesn't look great
|
| Also it isn't a criticism of my criticism, it is an
| assertion that I should not be allowed to criticise at
| all, which is a totally different thing. Of course I am
| going to call that out
|
| EDIT: I can't reply because rate limited
|
| Please calm down. I'm not threatening you. I'm simply
| surprised that you make such inflammatory and aggressive
| comments on an account that is so closely tied to your
| professional life, that is all. I think you should
| reconsider doing so
| mynameisvlad wrote:
| Oh so you jump to implicitly threatening those you
| disagree with? Wow. At least you made it clear how open
| you are to discussion and debate.
|
| I _never_ said you can 't criticize. As the other
| commenter already said, you're allowed to critique but
| don't be surprised when your criticism is then critiqued
| itself. That's the epitome of modern discussions and
| debate.
|
| I gave you examples of what _you_ can do right now, aka
| making your own alternative packages, but you chose to
| ignore that all and double down on "don't you dare
| critique my criticism".
|
| And then (I'm going to point this out again because it's
| so absurd) vaguely implied my comments would face
| professional retribution. Because I chose to disagree
| with you and make that public.
|
| In any case, I said I'm stopping and I am. You should
| too, as you're already crossing several lines with this
| comment.
| mxben wrote:
| > do not criticise
|
| Nobody said that. Of course you can criticize. But be
| aware that your criticism itself could be subject to
| criticism.
| bowsamic wrote:
| That's not really what's going on here though, because it
| isn't counter criticism, or a response to the criticism,
| but is instead simply "you shouldn't get to criticise"
| saagarjha wrote:
| Don't Rust crates go in a global namespace? In that case
| using up common or short names is definitely something I
| get to care about.
| daptaq wrote:
| At the very least it would be nice if languages could
| separate the interface from weird (I guess the idea is that
| they should be fun?) library names.
| omni wrote:
| Serde is a common term meaning
| "serialization/deserialization," seems pretty descript to me.
| jhgb wrote:
| 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.
| scubbo wrote:
| My $0.02 - I've heard of it and I've never worked in
| Rust, though calling it "a common term" seems like a bit
| of a stretch - I was over 5 years into my career before I
| encountered it. It's much less common than analogous
| terms like modem ("modulator-demodulator").
| omni wrote:
| I can assure you this Rust library did not invent the
| term
|
| https://trends.google.com/trends/explore?date=all&geo=US&
| q=s...
| jhgb wrote:
| Sadly all I'm constantly getting is "429. That's an
| error."
| ac29 wrote:
| https://en.wikipedia.org/wiki/SerDes
| jhgb wrote:
| This is a different namespace though. Nothing to do with
| data structures. Also, ends with an 's'.
| Cthulhu_ wrote:
| But... what and how does it serialize/deserialize?
| wongarsu wrote:
| Approximately everything, but on its own nothing. Serde
| provides the framework and macros/annotations, serde_json
| is the "backend" implementing the actual json
| serialization.
|
| Sure, it could be named serde_framwork and serde_json,
| but I think serde and serde_json isn't that bad either.
| hu3 wrote:
| 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
| avgcorrection wrote:
| 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?
| bowsamic wrote:
| Some Rust dependency bloat is pretty common, because a lot of
| idiomatic approaches are hidden behind dependencies. I don't
| think it's particularly crazy in this situation. The actual
| dependencies directly used are relatively lean:
|
| crossterm = "0.24.0"
|
| dirs = "4.0.0"
|
| regex = "1.5.4"
|
| serde_json = "1.0"
|
| serde = { version = "1.0", features = ["rc"] }
|
| textwrap = "0.14"
|
| unicode-segmentation = "1.7"
|
| I guess one could write their own textwrap and probably also
| dirs, but other than that they all are probably vital to this
| tool.
|
| The only reason this wouldn't be a problem in another language
| would be because that language already includes the
| functionality of such libraries
| chrismorgan wrote:
| You missed clap for the CLI because it was written in table
| form: [dependencies.clap] version = "3"
| default-features = false features = ["wrap_help",
| "suggestions", "std"]
| chrismorgan wrote:
| `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.
| reaperducer wrote:
| _hashbrown, smawk, corasick, parking_lot, itoa, ryu_
|
| Writing in Rust looks like casting spells in an Infocom game.
|
| Gnusto rezrov!
| mynameisvlad wrote:
| 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
| MichaelCollins wrote:
| atoi is a _classic_ example of the sort of bad naming C
| has long been infamous for. It 's not a word, it's an
| initialism, and the common documentation for it doesn't
| even say what the initialism actually means. It's
| relatively easy to infer what it means from the
| description of what it does ( _ascii to integer_ ), but
| can easily be incorrectly inferred ( _[character] array
| to integer_.)
|
| C kind of gets a pass for this stuff because C was old
| and in the early days they were limited by token size.
| But to still be using this term today _in a new language_
| seems fairly derisible.
| mgunyho wrote:
| Also, aho-corasick comes from the name of this algorithm
| that is named after its inventors https://en.wikipedia.or
| g/wiki/Aho%E2%80%93Corasick_algorithm
| enriquto wrote:
| What is the point of this function? In rust, there's no
| equivalent to sprintf?
| mynameisvlad wrote:
| 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.
| pie_flavor wrote:
| More accurately, some prefer a function that is
| statically dispatched and does not talk to
| std::fmt::Formatter.
| nicoburns wrote:
| In fairness, C standard library functions mostly look
| like magic incantations to me (I think due in large part
| to the old-school convention of abbreviating function
| names). malloc, sprintf, atoi, etc don't exactly read
| like english... (unless you happen to already know what
| they stand for)
| jonnycomputer wrote:
| 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.
| nibbleshifter wrote:
| Python is "batteries included", Rust isn't. Different
| design choices entirely.
|
| You can do a _lot_ with pythons stdlib, and a lot of
| popular libraries (requests, for example) largely are just
| usability wrappers for underlying stdlib stuff.
|
| Whereas with Rust, you have a very minimal std, and things
| you want to achieve are imported specifically.
| mixmastamyk wrote:
| requests is a wrapper around urllib3, which re-implements
| quite a bit.
| chrismorgan wrote:
| No, actually. Of the direct dependencies, Python's standard
| library has equivalents of regex (re), serde/serde_json
| (json), clap (argparse) and the boring half of textwrap
| (textwrap, which is only suitable for ASCII, and possibly
| curses providing a buggy and incomplete version of Unicode-
| and column-awareness, but I'm not sure of even that much,
| and I don't think it's properly cross-platform either), and
| some parts of crossterm (curses, of uncertain availability
| and reliability). But it completely lacks equivalents of
| most of crossterm and textwrap, and all of dirs and
| unicode-segmentation, providing in the latter two cases
| only functionality pretty much exactly equivalent to what
| Rust's standard library contains.
|
| This is the sort of thing that I meant by "doing things
| properly rather than half-heartedly". You could make
| something like this by reimplementing half the libraries in
| an inferior fashion, full of bugs, cross-platform
| inconsistencies and missing functionality. Or you can take
| an extra dependency. _Even in Python_ , the recommendation
| would be firmly to add dependencies like appdirs for dirs
| and I dunno what for the rest.
| wongarsu wrote:
| 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 :) )
| mxben wrote:
| > As soon as something enters the standard library its
| API is basically set in stone
|
| Is that really all that different from Python?
| chrismorgan wrote:
| No, that's the point: _if_ you put this stuff in the
| standard library, it gets frozen forever, and that's why
| Rust _doesn't_.
| infinityio wrote:
| To quote the python developers guide:
|
| > Because of Python's conservative nature when it comes
| to backwards-compatibility, when a module is added to the
| stdlib its API becomes frozen.
|
| So it sounds like they do do something fairly similar,
| but just a different mindset on adding libraries
| sayanarijit wrote:
| As long as there's no need to ship standalone binaries
| without shared libraries.
| mgunyho wrote:
| 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.
| chrismorgan wrote:
| It's a funny thing I've noticed about scripting
| languages: they're generally easier to get going with
| yourself, but they're _horrible_ for distribution
| /deployment, and if you have to integrate code written in
| other languages (even C libraries with Python bindings,
| or similar--things like wxWidgets or GTK), that rapidly
| escalates to a _nightmare_. Meanwhile, ahead-of-time
| compiled languages like Rust and Go are simply a breeze
| to distribute /deploy.
| mixmastamyk wrote:
| There are several working options for packaging Python
| apps, some existing for twenty years. Sure, while a
| little more complicated than compiling a static
| executable, it is hardly a "nightmare." It's basically
| writing a config file, and adding another stanza to a
| Makefile or modern equivalent.
|
| Reminds me of the idea regularly pushed here that you
| need a virtualenv even for thirty-line scripts. I read
| these kind of takes here often and am a bit baffled by
| them. Maybe it is because developers have lost
| administrator skills over time, that this feels like an
| insurmountable challenge?
| sayanarijit wrote:
| That static executable will basically contain the whole
| python interpreter with a huge standard library. Maybe
| makes sense for a gui app, but I'd avoid installing a
| whole python interpreter for each of my little cli tools.
|
| Don't forget the startup time overhead of first loading a
| whole interpreter into memory, then loading a python
| program into the interpreter.
| mixmastamyk wrote:
| There are multiple options for these requirements as
| well. I understand that solutions are sometimes clumsy,
| but the end-user won't know the difference.
| mgunyho wrote:
| That's true, although I think in the case of Go, it is a
| central design decision to make single-binaries easy so
| it's more of an exception to the rule.
|
| I don't think it's an inherent feature of scripting
| languages that they are hard to distribute. I'm pretty
| sure it's possible to package up a tiny Lua interpreter
| (or e.g. QuickJS) and all necessary scripts into a
| standalone file.
| sayanarijit wrote:
| Lua is only a configuration language without luarocks.
| With luarocks, we're back to the root of the argument -
| dependency vs standard library.
| nibbleshifter wrote:
| 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.
| jonnycomputer wrote:
| I'd prefer an informative rebuttal if people disagree
| with nibbleshifter, because I want to learn.
| avgcorrection wrote:
| Why don't you suggest dependencies that could be removed? Oh
| right. That would require effort.
| tempusr wrote:
| 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.
| mgunyho wrote:
| 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.
| kiwijamo wrote:
| How do you get vim to output the path to the directory you
| want?
| Beltalowda wrote:
| 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".
| StillBored wrote:
| Interesting.
|
| OTOH, people have named a number of similar tools, and I'm going
| to point out 'mc' aka Midnight Commander, which is part of most
| linux distro's, and is a clone of the 1980's Norton commander.
| Its designed to be a command line TUI helper, sorta like the
| project here, with not only cursor/etc based directory navigation
| but copy/rename/delete/etc functionality just a keystroke away.
| Its fairly convenient because it overlays the command line rather
| than replacing it.
| mwexler wrote:
| One of the better demo gifs: clever naming, clear utility, clear
| understanding of how to use the tool.
| Tepix wrote:
| This reminds me of "ncdu" which has the main task to let you know
| where your disk space has gone, but you can also use it to
| navigate folders and even delete stuff.
| p6way wrote:
| Not bad, my old stuff the same but c++/X11lib:
|
| https://youtu.be/2l7cIc4INAs?t=89
| amelius wrote:
| Makes me think of Norton commander.
| [deleted]
| chrismorgan wrote:
| 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 else as the
| remaining letters are fed to the next level down that you haven't
| even seen yet. My general habit in navigating is to type three
| characters and press Tab, because that's almost always
| sufficient, and is plenty fast. I have a very few places where
| I've learned to do other things. Under my habit, I could end up
| as much as two levels down from where I wanted to be.
| mgunyho wrote:
| 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.
| chrismorgan wrote:
| OK, delay sounds good.
| jonnycomputer wrote:
| 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.
| mynameisvlad wrote:
| > The auto-cd can also be turned off with a CLI option.
|
| Which was seemingly addressed as well, no?
| avgcorrection wrote:
| > that actively penalises fast typers,
|
| I think the word you are looking for is "indirectly".
| Aeolun wrote:
| That feels kinda direct though?
| chrismorgan wrote:
| 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".
| fouric wrote:
| 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).
| zelphirkalt wrote:
| Looks like Emacs built-in dired, except, that it is not
| integrated into Emacs.
| fouric wrote:
| It has fuzzy-filtering and auto-select - does dired have those?
| I think it's closer to helm-find-file.
| sayanarijit wrote:
| xplr author here (xplr.dev). Nice tool. Note that there's a
| plugin https://github.com/sayanarijit/type-to-nav.xplr that does
| something similar. But I just realized that tere can also be used
| as a more generic type-to-nav helper for xplr.
| xplr.config.modes.builtin.default.key_bindings.on_key.T = {
| help = "tere nav", messages = { { BashExec =
| [[echo ChangeDirectory: "'"$(tere)"'" >> "$XPLR_PIPE_MSG_IN"]] },
| }, }
| mgunyho wrote:
| Nice! Looks like xplr can indeed "integrate them all", as you
| say in the readme.
| smartmic wrote:
| Definitely worth to check out sdn which also serves perfectly as
| cd+ls replacement: https://git.janouch.name/p/sdn
|
| I also submitted few days ago here on HN:
| https://news.ycombinator.com/item?id=32081263
| mgunyho wrote:
| Indeed, this looks very similar! I added it to the list in the
| README.
|
| To compile it, I had to sudo apt-get install libacl1-dev, which
| was not mentioned in the instructions.
| progx wrote:
| Lol, ~30 years ago a created such a tool for DOS in Turbo Pascal
| for my own usage.
|
| Later i "upgrade" it to a Star Trek LCARS Design.... i have to
| look if i still had the sources.
|
| History repeats.
| mgunyho wrote:
| Yeah, I'll admit that the basic idea is not novel (I have a
| list of similar programs in the README). But I bet your tool
| doesn't work exactly the way _I_ like! :)
| progx wrote:
| That is true, it fits my needs that time. It is a nice memory
| of my first years of development.
| IshKebab wrote:
| This looks very cool. The demo has convinced me to try it, well
| done!
|
| Also typical hacker news - "why don't you just use Vim"? Ha.
| Ignore the naysayers.
| mgunyho wrote:
| I was well prepared mentally for the HN cynicism, and I did
| spend quite a bit of mental energy to justify the existence of
| tere to myself. Luckily I have a good rebuttal: I already use
| vim! :)
| p4bl0 wrote:
| > "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.
| maybevain wrote:
| 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.
| mgunyho wrote:
| I would say that terminal explorer is what I had in mind
| initially (and incidentally, I also speak Finnish, heh). But
| a misspelling of tree is certainly a valid interpretation as
| well :)
| pehtran wrote:
| Reminds me a bit of Helm mode in Emacs, nice!
| fouric wrote:
| This appears to be "helm-find-file" for those who want to use
| bash, and not Emacs.
| thyrox wrote:
| Sorry for being dense but I thought when I entered into a
| directory and pressed Esc it would pwd into that directory. But
| in my case, entering the dir and pressing esc just prints the dir
| name and doesn't pwd into it. I did the cargo install.. What am I
| missing?
| mgunyho wrote:
| You need to configure a shell function to actually do the cd
| (see the snippets in the README). It has to be done this way
| because a subprocess cannot change the pwd of the parent.
___________________________________________________________________
(page generated 2022-07-15 23:01 UTC)