nvim-telescope / telescope.nvim

Find, Filter, Preview, Pick. All lua, all the time.
MIT License
16.02k stars 838 forks source link

Allow setting mappings for extensions in telescope config #2470

Open lougreenwood opened 1 year ago

lougreenwood commented 1 year ago

Is your feature request related to a problem? Please describe. I'm not sure if this is already available, but recently I've been changing my default mappings to open buffers in new vim tabs.

However, for a number of my extensions this isn't suitable, for example I use telescope-alternate.nvim and would like <CR> to open the buffer in split in the current tab.

I also use telescope-tmux, but this means that telescope tries to open the tmux window in a new tab rather than switching to the actual tmux window.

For telescope-alternate, the author (@otavioschwanck) kindly added config to allow customising the mappings, however as I customise my setup more I realise that for each extension I use I will need to create an issue and either find the time to add mappings config to each extension or hope someone else can implement it (e.g https://github.com/camgraff/telescope-tmux.nvim/issues/6).

Describe the solution you'd like Ideally, telescope would provide an api for configuring mappings for extensions rather than requiring every extension to re-implement this logic (again, assuming it doesn't exist, maybe I missed this?).

This would help users to more easily configure their setup and reduce the maintain burden for developers.

Describe alternatives you've considered The only thing I've thought of is to create custom functions for each default telescope mapping which checks what the current extension / picker is and calls the correct function in that extension, else use the defaults. However I don't know if there's Telescope api to get the id / name of the current picker/extension (I guess so?) and it also requires that all telescope extensions expose public functions which can be called in the mapping.

Additional context Not sure if this overlaps with https://github.com/nvim-telescope/telescope.nvim/issues/1048 - I see that this is a plan to add a general interface for interacting with results. Maybe this will also be available for extensions and will allow customising mappings in some way?

jamestrew commented 1 year ago

The standard setup method for telescope functions should support custom mappings on a per-extension basis. A quick look at telescope-alternate.nvim shows an example as well.

-- You alternatively can call the setup inside telescope:
require('telescope').setup{
  extensions = {
    ["telescope-alternate"] = {
      mappings = {
        ...your mappings
      },
      presets = { 'rails', 'nestjs' }
    },
  },
}

Is this what you're looking for?

lougreenwood commented 1 year ago

Thanks @jamestrew, however the mappings key here is a "false friend", that's actually the "mappings" between alternate files.

But perhaps because this particular addon overwrites mappings maybe it made me not expect to be able to update the mappings.

Can you point to the Telescope docs for mappings with extensions so I can read more. I still can't find any docs from my search.

jamestrew commented 1 year ago

I'm not a user of telescope-alternate so I'm not familiar with the inner workings of how it handles mappings so you could be right.

I'm not sure if there are docs for extensions and how they should deal with mappings.

An alternative method might be to use the attach_mappings option (bottom of :h telescope.mappings).

I think there are ways to have a more "telescope" style mapping flexibility in extensions but ultimately it's up to the extension authors to do so. I think this issue is more about lacking documentation rather than a lacking feature :man_shrugging:

If you want to see an example of how extensions can support mappings cleanly, check out telescope-file-browser

hinell commented 1 year ago

Event though I agree that it's probably better to switch to require("plugin").setup() functionality for actual setup instead of relying on telescope itself. I think for now it may require a considerable amount of time for migration, simply because:

  1. Plugins will have to implement lua/plugin-name/init.lua files
  2. Implement support for mapping config (which often isn't implemented).