|
|
|
|
|
|
by hnlmorg
1432 days ago
|
|
|
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 :) |
|
|
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.