Telescope.nvim: Find, Filter, Preview, Pick | Hacker News Reader

Telescope.nvim: Find, Filter, Preview, Pick

github.com

153 pointspolm2337 comments

I'm not sure a direct link to the GitHub readme does this project justice if you're not already familiar with it (though the documentation is pretty good for someone who already knows what it is).

On the other hand I'm not sure how to describe it to a newcomer either, but at least I can do the crass "it's like this thing you may be more familiar with" which projects themselves don't like to say on their sites.

So if you use FZF on the command line or in Vim, check this out (there's wrappers for the actual FZF algorithm as well, though not by default), CtrlP is maybe the oldest Vim plugin that does this kind of thing and I think the various IDE implementations (which generally focus more on file or code locations than the Vim ones, which use it to enhance the keyboard interface generally) started with Textmate's Ctrl-T though maybe Sublime version is better known.

I'm very bullish on this being the best UI workflow for programmers, since we're dealing with a lot of textual information.

Is there anything you would say is a killer feature that fzf.vim[0] doesn't already provide? You get a similar UI from that, and nothing from their showcase section really jumped out at me as a must-have (though I have to admit that 95% of the time I only need :GFiles and :Buffers).

[0]: https://github.com/junegunn/fzf.vim

Shortest "killer feature" is probably the re-use of native vim buffers inside of telescope. So one cool thing is when it does a preview, it will show you the literal buffer (so it will have exactly the same colors, syntax highlighting, etc.) wherever possible.

Longer answer is I think it's quite cool to be able to not have to serialize/deserialize everything within telescope, so you can pass around objects (a.k.a. lua tables) that have function references, etc. that allow for very fun extension of the general API.

Another part I guess is that every part (that I have been able to think of thus far) is customizable. So you can change (per-search) the sorting algorithm, the display, the highlighting, the preview, the search text, etc. So you can fine-tune each aspect of it for the particular search or just your general preferences.

Also, I made it just because I was having lots of fun with it. I think fzf is a super awesome application (and plugin), so if it's working well for you I don't think I would switch!

Thanks for the answer!

Yeah, these all seem like power-user features for people that want more customization options, and I've more recently reverted to a simpler config with only the most necessary customization. I'll give it a proper try next time I redo my vim config!

No problem :)

Yeah (and I've said this elsewhere) I think people should use the tools that make them productive! So if that's fzf (or something else) then keep using that.

I honestly just made telescope for fun on stream to start with to explore some ideas about fuzzy finding that I thought would be fun. It just happened to be that people liked it and it grew.

We have a pretty active gitter group & people hanging out in the issue tracker, so feel free to ask questions there!

I covered this in answer to a similar sibling question so see that for in-depth thoughts.

For me personally, it's the coming together of a bunch of things that make it better, I'm not sure I can think of any one thing it does so much better than all competitors rather than just be a very good all-rounder. Maybe ease of code-level configuration counts, (e.g. replacing a function with a custom bit of code as part of "configuration") but not really a "feature" as such.

So it’s a fancy fuzzy finder? How is it different/better than fzf? Is it more integrated but therefore less flexible (e.g. less UNIXy)?

I read some early report on the neovim reddit where people complained that it was slower than fzf. So I did not bother looking into it more, also because no one could really explain it well.

I would say it's more integrated but also more flexible (only within neovim though. I don't have any good solution to run telescope from command line at this moment).

Each aspect of telescope can be customized (so you can change the sorting algorithm, the previewer, the search text, the format of the UI, etc). It was designed for vimmers to spend endless hours configuring (which is my favorite pasttime) ;)

The speed difference should be less now (for most of the pickers, I haven't fixed all of them yet), but fzf is (and probably always will be) faster than telescope.

It's a bit difficult to explain in short amounts, but I will hopefully put together a youtube series and/or some writing where I can explain it more succinctly. I usually feel like I have too much to say when it comes to telescope.

Ultimately though, I think if fzf is working well for you then I probably would not switch. fzf is really awesome!

That sounds really exciting, thank you so much for your work. I'll give it a try. Great new neovim prospects!

Thanks :) Hope you enjoy it!

For me it does so much more out of the box than fzf does. It takes advantage of the lsp to search your project in unique ways. Simply calling :Telescope will bring up a fuzzy list of all the built in commands making it far more discoverable than fzf was.

Check out the fantastic Gallery of uses

https://github.com/nvim-telescope/telescope.nvim/wiki/Showca...

Yes, it's a fancy fuzzy finder for NeoVim.

If you're already familiar with and enjoy FZF or CtrlP-like fuzzy finders in Vim interfaces then the tl;dr is "Telescope is to FZF as Neovim is to Vim'. It would be easy to say "they're both the same picture" and that would be very true to a degree but I'd say Telescope looks like the next evolutionary step in this area to me because:

- it's written in lua (I know for NeoVim this is like 'X rewritten in Rust' headlines are for the general HN audience, but thought I'd get it out of the way. I do believe this will lead to a faster/bigger development ecosystem and also provide a very Vim-appropriate degree of configurability for people who want to invest some time in coding to tweak their worflow.)

- The "speed" issue is mostly about implementing async-aware stuff so nothing blocks. This is a general trend in Neovim and it seems to be going well but people who tried it a while back may have hit issues and not seen the full benefit of this yet as it's an ongoing process.

- Like Ripgrep, the fastest search is the smartest search i.e. that doesn't actually search everything, and the configurability and still nascent UI experiments seems likely to lead to some optimums here as people specialize in different things.

- It assumes you have a recent (currently unstable nightly) version of Neovim, and takes advantage of that opportunity to make full use of NeoVim core changes at the design stage. You could probably ask the exact same question of "Why do I want Neovim if I'm fine with Vim?" and there's probably many good write-ups of that question that will transitively apply here as well.

- Because the basic UI it provides is a sweet spot of 'pretty, usable, fast, easy-to-build-on, configurable' and they're working with this connecting layer in mind it looks like it might absorb/replace a lot of other plugins that are currently reinventing wheels in this regard and let them focus on the bit they actually care about.

But yeah, it wouldn't exist without those other things existing before it and I'd be more excited to introduce someone to this whole world of tools, than this one in particular. But anyone using these kind of tools, should try this out, and probably the first impression for those people would be, "Oh that looks cooler" and then shortly after "I'm going to write my own plugin!".

Thank you so much for the thorough answer! There is a lot of exciting stuff for neovim rolling by e.g. on Reddit and I am already very happy with 0.5 so far. It is just hard to filter which new neovim/lua project is really worth the time to check out and potentially break your current setup. I will give it a try.

I wish the Denite plugin would get more direct credit as prior art here.

Yeah, I contributed to Denite and have talked to shougo about Denite as an inspiration for telescope.

It's a great project. I just added a note (which is the least I can do for the projects) here: https://github.com/nvim-telescope/telescope.nvim/commit/d466...

I think Denite doesn't get as much attention because it doesn't have sane defaults and instead requires you to configure everything yourself using a somewhat... peculiar configuration system. It's also known for sometimes breaking your workflow because why not.

I know I ignored it for a long time before I finally decided rolling up my sleeves in order to make it usable. I use it these days and am fairly satisfied, but there are still sharp corners which introduce friction continually because I dread having to investigate how to configure it.

It felt like an insane amount of friction, with a generous helping of “If you don’t grok this natively then it isn’t for you”. The fact that no attempt was made to preset a cohesive set of defaults since that should be “trivial” was a real speed-bump and turnoff.

I used to use Unite and Shougo's plugin manager, but his lack of communication or documentation, as well as just kind of abandoning projects when he felt like it, makes me no longer comfortable using his stuff.

Denite resolves Unite's problems. https://github.com/Shougo/denite.nvim

happy vim8 + Denite user here!, Telescope seems great as well can't wait to try it out eventually with nvim!

I haven’t checked out Denite yet. I’ve been using Unite, and I understand Denite is supposed to be better, but also requires you to do all of the configuration yourself.

Neovim 0.5 is awesome. It has native LSP support, Lua configuration support that it feels like true revolution over past versions.

But, getting into optimal setup in neovim/vim involves lot of configuration. Here is mine if you want to refer:

https://github.com/varbhat/dotfiles/tree/main/dot_config/nvi...

I’ve been meaning to convert my config to Lua. I haven’t tried out the official LSP support; I’ve been using coc.vim (https://github.com/neoclide/coc.nvim) which supports most of the VSCode plug-in API. Have you tried both? Curious how 0.5’s LSP implementation works for Typescript.

(My config is much simpler, a single vim script file: https://github.com/justjake/Dotfiles/blob/new/config/nvim/in...)

Official LSP is lightweight, much faster imo. You can try Typescript's tsserver with neovim-lsp .

I’m glad to hear that.

I’d heard a lot of good things about coc.nvim so I recently switched to it from languageclient-neovim. I have to say I am not very impressed. I don’t care for the configuration format, it’s not as flexible as I’d like, I don’t like installing npm packages to configure language servers that I already have installed, and it just generally feels sloppy.

I guess I’m going to need to break my LSP config yet again as I migrate over to the native client. Hopefully this is the last time…

That was my experience with coc as well. After getting over the initial configuration native LSP has been working great.

Also, you can use telescope to search for LSD definitions, references etc.

I’ve found lunarvim to be another good config baseline: https://github.com/ChristianChiarulli/LunarVim

Explained here: https://youtu.be/Qm864kVxAss

> LSP support

This one is quite underrated. Code highlighting, formatting, auto-completion and syntax checks. Doing that on old Vim was a time consuming task and usually something doesn't work, is missing or regularly breaks.

Since I started using coc.vim with neovim, it's as good as VSCode.

Hi everyone, I'm the creator of telescope :)

Happy to answer some questions / give my thoughts about telescope here.

Thanks!

Thank you, I was searching for this kind of plugin for a while! Great work!

Great <3 Hope you enjoy it! It was a lot of fun making it

Is there a generic name for interfaces that use this paradigm, something that would encompass Mac OS X Quicksilver/Alfred/Launchbar/Spotlight search, Chrome's Omnibox, FZF on the command line, Ctrl T/P in IDEs, etc.

I really like it and would like to adopt more things that use it. "Fuzzy finders" maybe? That doesn't really capture the autocomplete, hotkey to launch part of it which makes up the full flow in my mind.

If you're happy to ignore that initial part of entering the fuzzy search, "fuzzy search" or "fuzzy find" would have instantly registered in my mind those same examples you brought up. Maybe a qualifier, "on demand" or "by hotkey"?

Blueprint 3 calls their widget[0] for building this kind of experience “omnibar”.

[0] https://blueprintjs.com/docs/#select/omnibar

command palette or command bar are terms ive seen used

Hrm, I already do this with FZF in Neovim. Lots of ways to do a thing with vim!

First, I'll just say I think Telescope is a fantastic software/plugin and the developers have done a great job. It doesn't fit my needs exactly, but it works as advertised!

In my search for a file find plugin for [neo]vim I have come to realize that I really don't like "fuzzy" finders. I'm curious if anyone else shares this opinion as well, since I get the feeling from conversations like this one that FZF and related are overwhelmingly loved.

Reply on news.ycombinator.com